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ABSTRACT 

The  design  of  a  microprocessor  command  language,  RSCL, 
is  discussed.  BSCL  provides  the  capability  of  building 
variable  shell  environaents  on  a  standard  microprocessor 
system.  These  envircnaents  present  a  aenu  driven,  screen 
oriented  user  interface  as  opposed  to  the  line  oriented 
interface  of  current  operating  systaas. 

The  BSCL  is  a  straightforward,  easily  understandable  and 
complete  computer  programming  language.  Designed  according 
to  specific  command  language  guidelines,  it  allows  the  user 
to  make  maximum  utility  of  his  skills. 

A  prototype  implementation  and  sample  program  runs  are 
included.  These  illustrate  the  design  features  and  serve  as 
a  test  platform  for  future  research. 
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I.  IM  TBODUCTIQB 


km  B1CKGBOOM) 

In  the  early  days  of  coaputing  it  was  simply  man  against  the 
primitive  operations  of  the  computer.  There  was  no  need  for 
any  Coaaand  language  because  programming  was  done  bit  by  bit 
without  coaplex  interfacing.  Computer  systems  consisted  of 
aany  tubes,  a  few  cable  connections,  and  possibly  a  periph¬ 
eral  device  to  display  the  results  (output).  The  programmers 
of  the  early  days  were  considered  jack  of  all  trades.  They 
designed  the  rudiaentary  programs,  entered  them  bit  by  bit 
by  re-arranging  the  cable  configurations  and  should  problems 
arise  they  were  the  only  trained  maintenance  technicians. 
This  idyllic  situation  did  not  persist  for  long. 

advances  in  computer  technology  especially  in  regards  to 
resources  available  aade  it  iaperitive  that  the  user  ■  be 
given  soae  access  aechanism  to  these  resources.  The  first 
systea  to  provide  such  a  aeans  was  the  IBM  360.  The  system 
required  precise  instructions  to  execute  the  system  func¬ 
tions.  Unfortunately,  these  instructions  were  not  self 
generated  like  today's  systems  but  required  external  media 
intervention.  This  external  media  was  in  the  form  of  punch 
cards  each  containing  a  precise  coded  instruction  which  was 
then  feed  into  the  systea  along  with  the  program  card  deck. 
The  systea  designers  either  misconceived  the  effect  of  these 
cards  on  prograaaers  or  miscalculated  their  abilities  to 
achieve  an  autoaated  systea.  The  result  was  catastrophic. 
The  first  of  the  Coaaand  languages  was  a  piece  meal  language 
conceived  in  part  as  an  after  thought  to  a  poor  system 
design.  The  IBM  language  called  a  JCL  (Job  Control  Language) 
did  just  that,  it  controlled  the  program  execution  by  the 


insertion  of  instruction  cards  throughout  the  program  to 
manage  the  system's  resources.  The  language  was  ambiguous, 
inconsistent,  machine  dependent  and  designed  with  little 
concern  for  the  user.  The  impact  of  the  IBB  JCL  language 
spawned  numerous  reserch  efforts  several  of  which  are 
outlined. 

During  the  late  1960's  and  early  1970' s  several  organi¬ 
zations  established  working  groups  to  study  the  JCL  and  OSCL 
(Operaing  System  Control  Language)  interface  problem.  The 
first  organization  to  study  the  problem  was  the  American 
Standards  Institute  Committee  on  Programming  Languges  (ANSI) 
in  June  of  1967  [Ref.  1].  They  conducted  extensive  surveys 
of  nine  existing  0/S  systems  and  their  control  languages. 
Their  findings  concluded  with  a  list  of  five  recommendations 


1.  The  need  for  a  standard  OSCL  exists  and  its 
attainment  is  possible 

2.  Several  features  now  present  m  0/S  should 
not  be  included  in  the  standard 

3.  None  of  the  existing  OSCL's  surveyed  are 
suitable  as  candidates  for  a  standard  language 

<t.  There  should  only  be  a  single  standard  OSCL 
5.  Piecemeal  standardization  should  be  avoi' 


Pigure  1. 1  ANSI  OSCL  Study  Recommendations. 


for  a  design  proposal,  figure  1.1 

The  Dutch  established  committees  in  September  of  1971 
and  conducted  numerous  meetings  under  the  auspicies  of  the 
Netherlands  Centre  for  Informatics.  They  focused  on  the 
basic  functions  of  job  control  as  related  to  data  processing 
and  job  control  inputs.  The  committee  developed  a  list  of 
basic  job  control  functions,  Pigure  1.2,  is  a  synopsis  of 
their  classification  of  related  O/S  funcions. 


1.  Allocation  (of  resources) 

2.  Conditional  Selection  (of  part  of  a  job) 

3.  Execution  (of  a  computer  program) 

4.  Declaration  (of  job  attributes) 


Figure  1.2  Dutch  JCL  Committee's  Basic  Job  Functions. 

In  late  1972  the  CODASYL  (Conference  on  Data  System 
Languages)  organization  conducted  follow  on  studies  to  the 
ANSI  research.  They  determined  that  the  ANSI  committee  had 
only  addressed  the  feasability  aspect  of  a  standardized 
language  and  so  set  out  to  design  a  standard  OSCL  language. 
Three  working  goals  were  established  to  guide  the  research: 
investigate  the  functional  requiraments  for  communications 
between  the  user,  the  functional  program  and  the  hardware; 
determine  the  functions  necessary  to  define  a  standard  OSCL 
language  and  what  problems  such  a  language  would  have  on  an 
O/S ;  develop  linguistic  elements  which  posses  these  func¬ 
tions  and  define  a  machine- independent  OSCL. 

Since  these  early  studies  Other  organizations  i.e.  OS 
Federal  Information  Processing  standards  (FIPS),  IEEE,  ACM, 
British  computer  society,  OS  Department  of  Defense  (DOD)  , 
etc.  both  governmant  and  privately  sponsored  have  contrib¬ 
uted  to  the  research  and  development  of  several  prototype 
OSCL  languages. 

The  problem  of  standardizing  Command  Languages  has 
perpetuated  itself  over  the  years.  To  date  only  a  few 
languages  (systems)  merit  any  consideration  as  possible 
solutions. 


B.  PURPOSE 

The  purpose  of  this  project  was  to  design  a  system  which 
will  enable  the  user  to  easily  define  a  screen  oriented 
environment  (shell)  for  interfacing  to  microprocessor  based 
computer  systems. 

The  shell  provides  an  abstract  view  of  the  computer 
system  to  the  user.  Through  it  command  access  can  be 
controlled  and  a  standard  JCL  can  be  created  which  will 
operate  on  multiple  computers  and  operating  systems.  In 
this  way,  any  computer  system  can  be  tailored  to  perform 
exactly  as  desired  fcr  each  command.  In  addition,  the  same 
commands  can  be  made  to  execute  in  exactly  the  same  manner 
regardless  of  the  resident  operating  system.  This  can  have 
substantial  cost  saving  effects  in  locations  where  multiple 
computers  are  used.  Personnel  will  not  have  to  be  trained 
for  each  system  since  all  systems  will  operate  with  the  same 
JCL. 

C.  SCOPE 

Chapter  two  discusses  the  issues  involved  in  the  design  of  a 
command  language.  Guidelines  for  the  design  are  also 
presented.  The  features  of  the  command  language  are 
described  in  Chapter  three.  Chapter  four  discusses  the 
factors  which  were  involved  in  the  design.  The  assumptions 
made,  the  criteria  established  and  the  decisions  based  on 
them  are  listed.  A  prototype  implementation  is  described  in 
Chapter  five.  The  operation  of  the  system  from  the  point  of 
view  of  a  user  creating  a  shell  environment  with  the  command 
language  is  discussed  in  Chapter  six.  Our  conclusions  and 
recommendations  including  the  results  of  the  prototype 
implementation  are  presented  in  Chapter  seven.  Appendices 
A,  B  and  C  include  the  RSCL  grammar,  a  User's  Manual  for  the 
RSCL  and  a  CLI  program  source  code  listing  of  the  prototype 
implementation,  respectively. 


II.  COMM AMD  LAHGUAGE  IS§OgS 


A.  DESIGI  ISSUES 

Four  design  issues  confront  the  designers  of  any  interactive 
Command  language  [Bef.  2].  First,  hov  many  modes  of  opera¬ 
tion  should  the  user  be  forced  to  learn.  Second,  the  selec¬ 
tion  sequence  of  commands  should  be  consistent  and  not 
change  with  varying  machine  implementation  schemes.  Third, 
an  abort  mechanism  must  be  provided  to  the  user  to  terminate 
a  command  sequence  without  losing  the  current  scope  or  envi¬ 
ronment.  Finally,  a  clear  and  concise  error  message  system 
must  be  provided  to  quickly  resolve  syntactic  and  semantic 
problems.  Thase  design  issues  are  not  all  inclusive  and 
further  issues  will  be  brought  forward  as  the  need  arises. 

1.  CCB  MUSIC  ATI  ON  STYLES 

Many  CL  (command  language)  communication  styles  are  avail¬ 
able  today.  Direct  keyboard  entry,  using  pre-defined 
commands,  allows  the  user  to  directly  control  the  machine 
operations,  but  requires  the  user  to  learn  a  new,  possibly 
criptic,  language  for  each  os/machine  used.  Another  method 
uses  keyboard  response  dialogue  to  screen  prompts.  This 
method  is  easier  to  use,  but  requires  modification  of  the 
prompts  whenever  a  change  in  functions  is  made.  Function 
keys  are  a  third  method  for  users  to  communicate  with  the 
system.  They  are  very  fast  and  simple  to  use.  The  drawback 
with  this  method  is  some  machines  do  not  provide  a  function 
key  option  or  an  easy  means  to  redefine  the  existing  key 
functions.  The  last  communication  style  to  be  mentioned  is 
the  screen  menu  format.  This  style  is  seen  as  the  way  of 
the  future.  Commands  and  data  are  displayed  on  the  screen 
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in  menu  form.  The  user  references  the  comman d/data  by  posi¬ 
tioning  the  cursor  at  the  desired  field  or  by  marking  the 
position  with  a  light  pen.  Data  changed  on  the  screen  are 
correspondingly  changed  in  the  data  base.  criptic  one-line 
commands  to  the  o.s.  are  no  longer  required. 

Soae  systems  (Xerox  Smalltalk)  provide  a  controlled 
pointer  (aouse)  to  indicate  which  function  is  to  be  invoked. 
The  Apple  Lisa  system  uses  the  position  of  the  cursor  to 
highlight  a  chosen  function.  In  either  case  the  system  is 
screen  oriented  providing  the  user  with  a  simple  control 
mechanism  without  the  need  to  learn  another  language. 

2 .  DESIGN  G PIPELINES 

Several  scholars  have  suggested  guidelines  for  developing 
command  languages.  Bather  then  repeat  their  offerings  we 
have  consolidated  our  perceptions  of  the  primary  guidelines. 

.  The  systea  must  be  consistent.  It  must  present 
the  same  environment  to  the  user  regardless  of 
the  basic  systea  it  is  operating  on. 

.  The  system  must  provide  the  user  with  a  command 
sequence  which  is  easy  to  use  and  learn,  especially 
the  most  frequently  used  commands. 

.  The  systea  must  be  portable.  3ther  machines  must 
be  able  to  adapt  to  it  with  minimal  modification. 

.  The  system  must  provide  a  suitable  error  handling 
process,  both  in  presenting  error  messages  and  in 
saving  environments. 

.  The  systea  should  be  user  interactive  and  provide 
the  user  with  the  option  of  selecting  the  level  of 
prompt  help  he  desires.  Screen  oriented  displays 
are  very  helpful  in  selecting  operations,  but 
require  complex  interface  buffering. 


.  Control  structures  should  be  affluent  enough  to 
allow  the  user  total  control  of  the  programming 
environment. 

3.  USER  PROGRAMMING  LEVELS 

Different  levels  of  user  motivation  and  programming  experi¬ 
ence  must  be  considered  when  designing  a  multi-purpose 
Command  Language  system.  Figure  2. 1  shows  a  rough  categor¬ 
ization  of  potential  users  into  four  general  programming 
levels. 


1.  The  Toy  store  Programmer 

2.  The  Novice  Programmer 

3.  The  Computer  Club  Programmer 

4.  The  Paid  Programmer 


Figure  2.1  Four  User  Programming  Levels. 

The  first  level  is  the  "toy  store"  programmer.  He  does  not 
really  want  to  write  an  application  program,  but  just  wants 
to  know  enough  language  tools  to  run  a  simple  game  program. 
In  general,  he  is  in  total  awe  of  computers  and  makes 
minimal  use  of  their  actual  processing  capabilites. 

Progressing  to  the  second  level,  the  first  addres¬ 
sable  command  language  level,  we  have  the  user  who  may  have 
attended  a  programming  course  and  who  is  now  challenged  to 
write  a  few  simple  application  programs.  The  user  at  this 
level  is  enthusiastic  and  eager  to  try  out  his  new  skills. 
A  friendly  command  language  will  motivate  him  to  the  next 
level.  A  poorly  designed  command  language  will  be  frus¬ 
trating  and  quite  possibly  curtail  future  computer  queries. 

The  third  level  is  characterized  by  a  quantum  jump 
in  user  motivation.  and  usually  programming  skills.  These 
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users  really  vant  to  know  how  the  internal  system  works  and 
are  willing  to  expend  energy  and  their  own  time  to  learn 
varying  systei  hardware  and  software  configurations. 

The  final  level  is  a  grouping  of  two  user  factions 
into  one  entity.  They  are  colloguially  termed  the  learned 
computer  scholars  and  the  commercial  programmers.  They  say 
perceive  issues  from  different  perspectives,  yet  their 
motives  and  knowledge  of  computer  linguistics  are  compat¬ 
ible.  Beth  require  the  full  system  resource  capabilities  at 
their  immediate  disposed  in  order  to  perform  to  their  full 
potential. 

Realistically,  the  majority  of  today's  users  and 
those  who  are  of  concern  to  a  command  language  designer, 
fall  within  the  final  two  catagorie3.  However,  care  should 
be  taken  so  as  not  to  preclude  use  by  someone  at  the  second 
level. 

It  is  easily  understood  why  Command  Languages  are  so 
universally  divergent.  Designing  a  command  language  to 
satisfy  the  dynamic  needs  of  the  fourth-  level  users  while 
still  maintaining  the  simplicity  for  the  novice  users  is  not 
a  trivial  task. 

pismi  IQMJ12 

Another  issue  which  is  receiving  a  great  deal  of  attention 
as  the  state-of-the-art  is  the  display  format.  Whether  to 
display  data  as  individual  line  oriented  character  strings 
or  as  a  menu  driven  system.  The  traditional  theme,  driven 
by  the  hardware  limitations  of  the  past,  is  TTY  (teletyp- 
writter)  format.  i.e.  Presenting  a  line  at  a  time.  The 
user  responds  in  a  similiar  manner  by  entering  data  in  line 
oriented  fashion.  Innovations  in  hardware  have  enabled 
designers  to  break  from  tradition  and  display  whole  screen 
prompts  instantaneously. 


The  impact  of  these  innovations  has  been  seer,  is 
such  systems  as  the  Xerox  Smalltalk  and  the  Apple  Lisa.  i. 
a.  Incorporating  the  traditional  command  language  line 
editing  commands  into  onscreen  menu  controls.  The  respose 
from  critics  to  these  nont raditonal  systems  has  been  over¬ 
whelmingly  positive. 

The  real  significance  of  these  systems  is  their 
prime  objective.  They  strive  to  provide  the  user  with  a 
friendly  interface  devoid  of  complex,  ambiguous  and  incon- 
sistant  command  language  structures.  To  the  "real1*  program¬ 
mers  these  systems  appear  as  a  threat  to  their  mythical  man 
over  machine  syndrome.  Many  feel  that  programming  is  an  art 
and  a  science  and  that  these  systems  take  away  their 
creativity  by  restricting  how  they  can  address  the  computer. 
They  prefer  to  deal  direct  rather  than  through  the 
middleman.  In  reality,  a  friendlier  interface  places  no 
such  restrictions.  It  simply  makes  it  more  understandable 
so  that  more  users  can  address  the  computer  direcly.  Until 
we  overcame  the  system  friendliness  problem  only  those  in 
the  "real"  programmers  category  will  be  willing  and  able  to 
fully  utilize  the  computer. 

These  systems  still  have  some  drawbacks  such  as 
overall  cost  and  high  memory  requirements.  Y9t,  given  the 
history  of  the  microprocessor,  hardware  designers  will  over¬ 
come  the  obstacles  and  make  these  features  available  to  the 
average  user. 

The  command  languages  of  tomorrow  will  employ  the 
ease  of  onscreen  control  with  the  user  friendliness  of 
multi-screen  display. 


hi.  S2MU2  LAisgiss  misii§ 


A.  BSCL  COHHAHDS 

Tha  BSCL  coaaands  ware  chosen  based  on  the  guidelines 
outlined  in  chapter  two.  Simplicity  of  use,  coupled  with 
conciseness  in  definition  and  execution  were  paramount  in 
choosing  the  BSCL  coaaands. 

Research  and  practical  experience  indicates  that  many 
coanand  languages  are  either  to  baroque  or  to  simple  for 
their  intended  purpose.  While  the  BSCL  does  not  encompass 
all  possible  prograaaing  language  capabilities,  it  does 
fulfill  the  ainiaua  requirements  of  a  complete  language. 
And,  it  does  establish  a  user  friandly  framework,  a  design 
goal  stated  in  chapter  one. 

Standard  coaaand  naming  conventions  i.e.  if-t hen-else, 
put,  case  etc.  were  adopted  whenever  possible.  The  syntax 
structure  does  not  deviate  from  established  norms,  while  the 
semantics  of  the  command  language  avoids  ambiguity. 
Exception  processing  and  type  conversion  is  not  performed 
nor  is  it  implied  in  any  of  the  commands.  If  the  system 
does  not  know  what  you  intended,  it  tells  you  via  an  error 
message.  If  data  types  do  not  match  across  an  assignment 
operation,  the  assignment  is  not  permitted. 

1-  Jjfllil  LI  ZZAmiZ 

Several  features  have  been  built  into  the  BSCL  which 
simplify  both  the  language  itself  and  the  programs  written 
in  the  language. 

.  Dynamic  data  typing  (offsets  declaration  requirements). 

.  Both  interactive  and  file  processing  capabilities. 

.  Automatic  file  opening  and  closing  operations  performed 


on  both  the  POT  and  the  GET  cooaands. 

.  Format  free  statement  entry. 

.  Stateaents  aay  be  entered  in  either  upper  or  lower  case. 

2.  liamas  iisinxiass 

The  language,  as  designed,  has  the  following  limitations: 

.  Arrays  and  data  structures  are  not  defined. 

.  Only  decimal  integers  aay  be  represented. 

.  Floating  point  arithmetic  is  not  supported. 

.  Unary  operators  are  not  supported. 

.  Exponentiation  is  not  supported. 

In  the  prototype  implementation  the  following  addi¬ 
tional  contraints  were  placed  on  the  system: 

.  Loop  statements  aay  not  be  nested. 

.  Only  one  3tring  variable  aay  exist  at  any  time. 

3.  LANGUAGE  COMMANDS 

The  ten  RSCL  commands  were  chosen  as  the  minimum  number 
required  to  facilitate  the  requirements  of  a  screen  oriented 
coaaand  language. 

The  following  is  a  brief  description  of  each 
coaaand.  For  a  detailed  description  see  the  RSS  Command 
Language  User's  Manual,  Appendix  B. 

a.  LET  coaaand 

The  LET  coaaand  serves  as  the  assignment  statement.  The 
variable  on  the  left  hand  side  (LHS)  of  the  "s*1' ,  receives  a 
value  free  the  right  hand  side  (RHS)  .  The  RHS  can  be  either 
an  expression,  an  integer,  a  string,  or  another  variable 
(containing  a  value  of  the  same  data  type)  .  If  the  RHS  is  a 
legal  arithemetic  expression,  its  value  is  computed  and  the 
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result  is  assigned  to  the  variable  on  the  LHS.  otherwise, 
the  value  of  the  RHS  is  directly  assigned  to  the  variable  on 
the  LHS. 


b.  The  POT  command 

The  POT  coaaand  consists  of  three  parts;  the  device,  an 
optional  line  skip  parameter  and  the  data  list.  It  outputs 
newlines  and  the  iteas  specified  in  the  data  list  to  the 
named  device. 

Valid  devices  are:  "LST",  the  system  line 
printer;  "CRT",  the  user’s  console  screen  and  <FN>  the  name 
of  a  disk  file.  The  device  name  aay  be  followed  by  the  word 
"skip"  (performed  only  once  per-coamand)  .  Bach  occurrance 
causes  a  newline  character  to  be  output.  The  data  list 
contains  any  combination  of  variables  and  strings  (a  string 
consists  of  any  characters  contained  within  double  quote 
symbols  "  ") .  The  value  of  the  variable  and  the  actual 

character  string,  minus  the  quote  narks,  will  be  output. 

c.  The  GET  Coaaand 

The  GET  command  reads  data  from  either  the  user's  console  or 
from  files  stored  on  the  user's  disk.  The  device  name 
("CRT",  <FN>)  proceeds  the  receiving  variables  and  indicates 
which  medium  the  user  wishes  to  access  for  his  data. 

d.  IF  coaaand 

The  IF  coaaand  is  used  to  logically  select  whether  or  not  to 
execute  a  particular  set  of  stateaents.  It  has  three  compo¬ 
nents;  a  logical  expression,  a  THEN  set  of  statements  and  an 
optional  ELSE  set  of  statements.  The  value  of  the  logical 
expression  is  computed.  If  the  expression  result  is  true, 
(value  not  equal  0),  the  THEN  group  of  stateaents  is 

executed.  Otherwise,  the  ELSE  group  of  statements  is 

executed.  If  no  ELSE  group  is  included  execution  continues 
after  the  end  of  the  IF  statement. 


e.  The  CASE  Conaan  d 


The  CASE  connand  provides  for  the  execution  of  one  or  more 
statements  contained  within  at  least  one  sublease.  The 
sublease  is  entered  if  it's  corresponding  case  label  matches 
the  value  of  the  CASE  statenent  parameter  (variable  or 
integer)  .  If  no  sublease  label  matches  the  label  of  the 
case  value,  the  OTHERWISE  set  of  statements  is  executed. 

f.  The  LOOP  command 

The  LOOP  command  consists  of  two  parts;  the  loop  iteration 
parameter  and  the  body  of  statements.  All  of  the  statements 
included  within  the  body  of  the  loop  are  repeated  a  number 
of  tines  equal  to  the  value  of  the  loop  iteration  parameter. 
If  this  value  is  less  then  or  equal  to  0,  no  statements  are 
executed. 

g.  The  COHHENT  Command 

The  CCBMENT  command  performs  no  actual  processing.  Its 
purpose  is  to  allow  the  user  to  document  his  program  and  to 
structure  it  in  a  logically  understandable  fora.  A  comment 
begins  with  a  and,  as  all  other  RSCL  statements,  it 

terminates  with  a  "i".  Everything  contained  within  these 
two  semicolons  is  ignored. 

h.  The  LOCATE  Command 

The  LOCATE  Command  is  used  to  determine  the  current  location 
of  the  cursor.  It  returns  the  row  and  column  number. 

i.  The  POSITION  command 

The  POSITION  Command  is  used  to  place  the  cursor  at  a 
particular  point  (row  and  column  position)  on  the  screen. 
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j.  The  CREATE  Command 


The  CREATE  Command  is  used  to  generate  a  screen  template. 
It  consists  of  two  parts;  the  template  identifier  and  from  1 
to  24  line  definitions. 

The  template  identifier  is  a  variable  name  used 
to  differentiate  one  template  from  another.  The  line  defi¬ 
nitions  specify  up  to  80  fields  pec  line  and  their  associ¬ 
ated  attributes. 

k.  The  DISPLAY  Command 

The  DISPLAY  Command  causes  a  screen  template  and  its  associ¬ 
ated  data  to  be  output  to  the  user's  console  screen.  It 
consists  of  two  parts;  the  template  identifier  and  an 
optional  set  of  parameters. 

The  template  identifier  is  a  variable  name 
supplied  by  the  CREATE  command  when  it  generated  the  temp¬ 
late.  The  parameters  include  a  line  number,  a  field  number 
and  text.  The  line  and  field  numbers  specify  exactly  where 
on  the  template  the  text  has  changed.  These  parameters  are 
returned  by  the  display  manager  whenever  the  data  in  a 
particular  field  has  changed. 
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I?.  ST  STBS  DESIGH 


A.  DESIGH  ASSDHPTIOHS 

Boar  major  design  assumptions  were  aade  early  in  the  design 
phase.  First,  the  integrated  system  is  intended  to  operate 
on  either  8  or  1 6  bit  microcomputers. 

Second,  the  interfaces  between  the  host  operating 
system,  the  coaaand  language  and  the  Display  Manager  are  all 
transparent  to  the  user.  The  usa  of  abstract  interfaces 
between  these  three  aodules  enables  the  system  to  be  readily 
transportable  to  various  microcomputers  and  operating 
systeas. 

Third,  aaaory  utilization  was  not  considered  a  prime 
concern.  The  current  trends  in  the  state  of  the  art  towards 
larger,  cheaper  aeaories  lead  us  to  believe  that  the  differ¬ 
ence  of  cne  or  two  thousand  bytes  out  of  possibly  one  mega¬ 
byte  of  storage  is  insignificant. 

Fourth,  processing  speed  was  considered  important, 
although  not  paramount  in  the  design.  Since  the  system  is 
to  be  in  continuous  operation  serving  as  the  interface 
between  the  user  and  the  imbedded  operating  system,  some 
overhead  is  acceptable  in  exchange  for  the  added  capabili¬ 
ties.  This  overhead  should  occur  during  the  user's  "think" 
time  rather  than  during  actual  processing. 

B.  OESIGH  CRITERIA 

Several  criteria  were  considered  during  the  design  phase. 
Clarity,  siaplicity,  portability,  maintenance  and  upward 
compatibility  were  all  key  factors  in  designing  the  system. 
The  ultimate  goal  was  to  design  a  system  that  incorporated 
the  features  outlined  in  chapter  two  in  a  clear  and  concise 
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aanner  without  overburdening  the  user.  The  limited  number 
of  language  commands  is  a  direct  attempt  to  demonstrate  that 
a  command  language  can  be  simple  and  can  function  clearly 
without  an  excessive  number  of  nebulous  commands.  The 
sample  programs  listed  in  the  users  manual  demonstrate  the 
clarity  of  command  usage. 

The  use  of  a  high  level  system  programming  language, 
"C" ,  serves  to  grant  the  desired  portability.  "C"  compilers 
are  available  on  many  micro,  mini  and  mainframe  systems. 
Cross-compilers  should  be  available  for  those  systems  which 
do  not  have  a  "C"  compiler. 

The  VAX  computer  was  u3ed  for  development  of  the  proto¬ 
type  system.  Its  processing  capabilities  and  myriad  of 
supporting  functions  along  with  its  multiprogramming  oper¬ 
ating  system  and  the  availablity  of  a  competent  support 
staff  made  it  more  suitable  for  development  than  a  single 
user  micro  system.  The  use  of  any  features  unique  to  the 
VAX  is  purely  accidental.  To  assure  program  portability, 
only  standard  MC"  programming  features  were  used. 
Extensions  and  system  dependant  features  must  be  avoided  in 
any  implementation. 

Program  maintenance  is  supported  by  rhe  use  of  a  higher 
order  programming  language,  functional  decompostion, 
abstract  interfaces  and  structured  programming  techniques. 
The  utility  of  these  factors  was  directly  observed  during 
the  debug  and  test  phases  of  the  prototype  implementation. 

In  addition,  the  use  of  a  higher  order  language,  the 
simplicity  of  the  language  design  and  the  avoidance  of 
nonstatndard  features  ensures  some  degree  of  upward  system 
compatibility. 


C.  DESIGH  DECISIONS 


Three  major  design  decisions  were  faced  during  the  develop¬ 
ment  of  the  command  language.  First,  which  language  should 
be  used  to  inclement  the  system.  second,  certain  grammar, 
structure  and  i  irple mentation  conventions  had  to  be  adopted 
in  order  to  ensure  system  integrity.  Third,  the  interfaces 
between  the  operating  system,  the  command  Language  module 
and  the  Display  Manager  module  was  uncertain. 

"C"  was  chosen  to  implement  the  system  because  of  its 
inherant  system  design  features.  It  was  originally  designed 
as  a  system  development  tool.  As  such,  it  was  felt  to  be 
the  most  suitable  language  for  our  purposes. 

In  designing  the  BSCL  grammar,  standard  conventions  for 
representing  the  lexical  ordering  and  syntax  of  the  language 
were  devised.  These  conventions  were  documented  and  are 
included  with  the  grammar  itself  in  Appendix  A.  The  use  of 
these  standards  was  necessary  in  order  to  assure  that  we 
both  interpreted  the  grammar  in  a  like  way  and  that  separate 
modules,  which  were  coded  independently,  would  operate  in  a 
like  manner. 

Prior  to  initiating  the  actual  coding  phase,  several 
sessions  were  held  tc  establish  programming  guidelines  and 
intermodule  interfaces.  Global  variables,  data  types,  error 
handling,  system  diagnostic  and  integration  standards  were 
defined.  Any  changes  or  variations  from  these  established 
guidelines  were  discussed  and  agreed  upon  before  being 
incorporated  into  the  respective  functions.  This  practice 
proved  to  be  invaluable  daring  the  integration  and  test  of 
the  prototype  system.  No  significant  interfacing  problems 
were  encountered. 

The  last  major  design  decision  concerned  interfacing  the 
command  language  interpreter  (CLI)  with  the  resident  oper¬ 
ating  system  and  with  the  Display  Manager  program.  Neither 
of  these  interfaces  was  built  into  the  current  system. 


Instead,  abstract  interfaces  were  planned  for  each  of 
these.  The  operating  system  interface  will  be  a  function 
call  with  a  character  string  parameter.  For  example,  to 
change  the  name  of  a  file,  a  rename  function  would  exist. 
This  function  would  reguire  two  parameters;  the  old  file 
name  and  the  new  file  name.  The  file  names  are  expected  to 
be  complete.  Information  such  as  the  disk  drive  designator 
should  be  included  in  the  name  whether  or  not  the  user 
enters  it.  The  rename  function  would  then  cause  the  oper¬ 
ating  system  to  change  the  name  of  the  file  in  whatever  ways 
it  feels  is  optimal.  It  is  transparent  and  irrelevant  to 
the  (CLI) ,  whether  a  separate  command  to  the  operating 
system  is  generated  or  the  data  is  sent  to  the  BIOS  or  the 
disk  file  directory  is  changed.  In  this  way,  a  change  in 
the  underlying  operating  system  will  require  a  change  in 
only  these  interface  functions.  It  makes  no  difference  to 
the  majority  of  the  system  whether  a  file  name  is  changed  by 
an  "mv"  command  as  in  VAX  UNIX,  an  "ren"  command  as  in  CP/S, 
an  "r"  command  as  in  VMS,  etc.  The  implementation  of  these 
functions  is  currently  the  topic  of  a  separate  thesis  at  the 
Naval  Postgraguate  School. 

The  interface  to  the  Display  Manager  module  was  not 
implemented  because  it  was  planned  to  use  a  pre-existing 
program.  A  commercial  product,  called  "Display  Manager"  is 
available  from  Digital  Besearch.  This  program  does  all  that 
we  needed  in  the  BSCL  system.  It  also  is  capable  of  inter¬ 
facing  directly  with  a  program  written  in  the  "C"  language. 
Rather  than  devote  time  to  development  of  a  new  program  with 
similar  capability,  it  was  decided  to  purchase  and  use  the 
Digital  Research  Display  Manager.  Our  efforts  were  spent 
defining  the  display  data  which  were  of  concern.  This 
information  is  included  in  the  language  grammar  within  the 
"create"  command.  The  actual  commands  telling  the  Display 
Manager  what  to  display  are  included  in  the  grammar  within 
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the  "display"  coaaand.  Coding  of  these  functions  was  post¬ 
poned  until  the  prograa  could  be  purchased.  At  that  time 
the  actual  interfacing  parameters  required  can  be  determined 
and  the  functions  can  be  written. 


f.  IBP LBHBMTATI01 


k.  DATA  OBGAHIZATIOH 

The  language  data  organization  is  broken  up  into  two  parts, 
local  and  global  variables.  Local  variables  are  used  within 
each  function  to  handle  internal  data  transactions.  Data 
shared  between  two  functions  is  passed  globally.  The  global 
variables  are  declared  in  a  central  file,  "global. interp", 
to  maintain  tight  control  over  their  assignment  and  use. 
Using  glcbal  variables  to  transfer  external  data  decreased 
the  system  execution  time,  while  making  the  functions 
cleaner  and  easier  to  integrate.  The  design  specifications 
clearly  define  each  global  variable,  its  use  and  what  func¬ 
tions  utilize  it's  values. 

Comments  are  generously  dispersed  throughout  each  func¬ 
tion  to  aid  the  user  in  understanding  its  purpose.  A  header 
is  appended  to  the  beginning  of  each  function,  listing  the 
other  functions  called  and  th9  global  variables  and 
constants  used  within  the  function. 

B.  PBOGBAB  OBG  A  BIZ  ATIOH 

Functional  decomposition  was  used  extensively  throughout  the 
program.  Three  separate  modules  comprise  the  fully  inte¬ 
grated  system.  The  0/S  module  is  a  set  of  functions  which 
defines  the  interface  to  the  host's  operating  system.  These 
functions  translate  commands  from  the  CLI  to  the  native 
language  of  the  0/s.  Those  commands  that  are  not  native  to 
the  host  will  be  software  emulated,  if  possible. 

The  language  interpreter  module  has  a  dual  function.  It 
interfaces  with  both  the  0/S  and  display  modules.  Programs 
generated  either  interactively  or  by  batch  mode  are 


processed  through  the  language  interpreter.  Output  from  the 
interpreter  is  a  series  of  instructions  to  one  of  the  other 
two  eodules. 

The  last  link  in  the  triad  is  the  display  nodule.  Like 
the  O/S  module,  it  receives  its  data  froa  the  interpreter 
through  the  interface  connands.  The  display  module  takes 
data  stored  in  a  file  and  transposes  it  onto  one  of  the 
foraats  generated  by  the  create  comaand. 


C.  BOBTIME  EBBOB  CHECKING 

A  run  tiae  error  handler  is  built  into  the  system  and  is 
activated  when  an  invalid  comaand  sequence  is  encountered  by 
the  interpreter.  ill  error  nessages  are  contained  in  a 
single  error  function.  When  an  error  is  detected  the  error 
handler  is  called  and  prints  a  diagnostic  message  and  ampli¬ 
fying  information.  Depending  on  the  severity  of  the  error 
either  the  program  is  terminated  or  control  is  returned  to 
the  calling  function. 


ti.  SISIM  0£M4II2I 


The  BSCL  is  capable  cf  operating  either  in  an  interactive  or 
a  batch  aode.  Por  batch  mode  operation,  programs  can  be 
written  using  any  standard  text  editing  program.  The  file 
containing  tha  source  code  must  be  called  "BSCL". 

At  execution  time,  the  CLI  determines  if  a  file  exists 
with  the  name  "RSCL".  If  one  is  found,  it  is  assumed  to 
contain  the  source  statements.  The  CLI  then  executes  in  a 
batch  mode  taking  its  input  from  the  source  file. 
Otherwise,  the  CLI  reads  its  instructions  from  the  user's 


HI.  COSCLDSIOH  S  4.22  BECQHMEHDATIOHS 


The  command  language  design  and  a  prototype  implementation, 
have  been  completed.  This  design  is  now  reviewed  to  deter¬ 
mine  which  of  our  original  goals  have  been  met  or  can  be  met 
with  further  work  and  which,  if  any,  were  not  found  to  be 
feasible. 

1.  GOALS 

The  goal  of  this  work  was  to  design  a  command  language  which 
runs  on  microprocessor  based  computer  systems.  The  purpose 
of  the  language  was  to  allow  rapid  definition  of  a  screen 
oriented  user  interface.  The  language  was  to  be  simple, 
easy  to  use  and  readily  understandable.  Maintainability  and 
portability  across  different  machines  and  operating  systems 
were  prime  concerns.  Processing  efficiency  was  considered, 
but  only  secoadarily  to  the  other  factors. 

B.  PBOBLEM  ABBAS 

The  BSCL  is  complete  and  workable  as  designed.  Known 
problem  areas  which  are  stated  as  constraints  in  the 
language  are  not  inherent  problems.  They  can  be  eliminated 
during  future  enhancements.  The  only  area  which  we  see  as  a 
potential  problem  to  the  system  design  is  related  to  the 
Display  Manager  interface.  The  design  in  this  area  was 
purposefully  made  generic  via  th9  principles  of  abstract 
interfaces  and  information  hiding.  However,  if  the  func¬ 
tions  required  by  the  CLI  are  not  available,  some  redesign 
may  be  necessary.  Because  of  our  research  in  the  area 
before  creating  the  design,  we  do  not  feel  this  is  a  major 
concern.  The  CLI  module  should  be  easily  interfaced  to  the 
other  two  major  system  modules  when  they  become  available. 


C.  FUTURE  BOBK 


In  order  to  create  a  complete  and  deliverable  product 
further  work  is  required  in  four  areas;  the  operating  system 
interface  routines  must  be  completed,  enhancements  must  be 
added  to  eliminate  the  constraints  discussed  in  Chapter 
three,  the  three  main  system  modules  must  be  integrated, 
studies  should  be  performed  to  determine  user  needs  and 
reactions. 

The  operating  system  interface  routines  are  already 
being  developed  under  a  separate  thesis  effort  at  the  Naval 
Postgraduate  school.  Assuming  that  a  copy  of  the  Display 
Hanager  Program  is  obtained  from  Digital  Research  and  that  a 
"C"  compiler  is  available  for  the  NPS  microprocessor  system, 
the  system  enhancements  and  module  integration  can  be  accom¬ 
plished  under  another  thesis.  Concurently  with  the  system 
integration,  research  should  be  performed  to  determine 
sample  presentation  formats.  They  could  then  be  created  in 
the  RSCL. 
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CO  H  HAND  LANGUAGE  GBAHHAB 


The  convention  used  for  describing  the  grammar  of  the 
command  language  is  described  in  table  I. 


TABLE  I 

Grammar  Convention 

SXflSSi  SSkUM 

< 

> 

Used  as  delimiters  for  matasymbols 
in  the  grammar.  Anything  contained 
within  these  brackets  is  defined 
later  in  the  grammar. 

c 

3 

Used  as  delimiters  surroanding 
optional  entries. 

1 

t 

U$ed  as  delimiters  surrounding 
lateral  expressions  in  the  grammar. 

Anything  within  these  symbols  must 
appear  exactly  as  shown. 

1 

Used  as  a  logical  OB. 

• 

• 

:* 

Interpreted  as  "Defined  as". 

( 

) 

Used  to  group  expressions. 

**N 

i 

Used  to  designate  a  repetitive  gpoup. 
where  "N"  is  the  number  of  repetitions. 

j 

Using  this  convention  the  Cooaand  Language  Grammar  is 
defined  as  follows: 

PHOGHAM  'PBOGHAH  •  <IDENTIFIER>  <STATEHENTS>  'END.' 

STATEHENTS  : (  <LET  STATEHENT>  I  <IF  STATEHENI> 
f  <PUT"STAIEHENT>  |  <GET  STATEMENT> 

<LOO?  STAT  EMENT>  I  <CA5E  STATEMENT 
<COHHENT>  I  <DISPLAI>  |  ^CBE ATE>  ) 

[  <STATEHENTS>  ] 


■r.y, 

<.v. 


,W- 

•u'  . 


LET_ STATEMENT 

IF_ST ATEMENT  : 

POT_ STATEMENT 
PUT— DEVICE 
LIST 

GET_ STATEMENT 
GET_DEVICE 
ID_LIST 
FNAME 

LOO  ?_  ST  AT  EM  ENT 
CASE_STATEMENT 
CASE  NOM 


:=  'LET*  <ID  ENTIFIES>  •  =  '  (  <EX?RESSION> 

|  <IDENTI FIER>  |  <NUMBER>  |  <STRING>  ) 

*  'IF*  <L03  EXP>  'THEN'  <STATEMENTS> 

['ELSE'  <STATEMENTS>  ]  '  ENDIF ' 

:=  'POT'  <PUT_DEVICE>  [  'SKIP'  ]  <LIST> 

:=  'CRT'  1  ' LST'  |  <FNAME> 

:=  (  <IDENTI FIER>  |  <STRING>  )  [<LIST>] 

:=  'GET'  <GET_DEVICE>  <ID_LIST> 

:=  'CRT'  |  <FNAME> 

:=  < IDENTIF IER>  [  <ID_LIST>  ] 

:=  [  <CHARACTER>  ]  <IDENTIFIER> 

t  '.'  <IDENTIFIER>  ] 

:  :a  'LOOP'  t  <IDENTIFIER>  |  <NUMBER>  ) 
<STATEMENTS>  'ENDLOOP' 

:  'CASE'  <IDENTIFIER>  <CASE  NUM> 

•OTHERWISE:'  <STATEMENTS>  'ENDCASE* 

(<NUHBER>  1  <IDENTIFIER>)  »:•  <STATEMENTS> 
[  <CASE_NUM>] 


COMMENT 

IDENTIFIER 

SOB_ID 

EXPRESSION 

SUB.EXP 

TERM 

LOG_EXP 

SUB_LOG 

LOG_TEHM 

SPACES 

NUMBER 

CHARACTER 


=  <ANYT  HIN  G> 

*  <CHARACTE R>  [<SUB_ID>] 

*  C  3  (<CHAR  ACTER>  |  <DIGIT>)  [<SUB_ID>] 

*  '  (»  <TERM>  [  <ARITH_OPR>  <SUB_EXP>  ]  ')• 

=  <TERM>  [  <AHITH-OPR>  <SUB_EXP>] 

=  <EXPRESSION>  |  <IDENTIFIER>  |  <NUMBER> 

*  '  ('  <LOG_TER  M>  [  <L03_0PR>  <SUB_LOG>  ]  ’)' 

=  < LOG  TERM>  [  <LOG  OPR>  (  <SUB  LOO 
|  <LOG_EXP>  )  ]  ” 

=  <LOG_EXP>  |  <IDENTIFIER>  |  <NUMBER> 

*  '  *  |  '  '  <SPACES> 

=  <DIGIT>  |  <DIGIT>  <NUMBER> 


«  •  A' 

•B* 

•C* 

•  D' 

•  E' 

'F' 

'  H' 

•I' 

'J* 

'  K  ' 

•L' 

•M' 

'O' 

*P' 

*  Q ' 

'R' 

•S' 

'  T ' 

•  V* 

•H' 

•X' 

'!• 

•Z' 

•a» 

•c' 

•d* 

•e ' 

•f  • 

•  gt 

•h' 

•  j* 

•k« 

•1' 

l  B' 

•n' 

•  o' 

•  q* 

'  X* 

•r' 

•r 

•s' 

•z* 

't* 

•  u' 

'7' 

DIGIT  'O' 

1  '1' 

'2'  |  '3' 

I  '4*  |  *5'  |  '6*  j 

1  '7' 

J  '8» 

'  9 ' 

ARITH_QPH  j  '-•  |  •  *'  |  •/» 

LOG_OPR  *EQ '  |  »LT*  \  ' GT '  I  ' NE '  |  *LE»  |  ' GE' 
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v  *■  -s  •' 


LOG_PONC  ::  = 
STRING  ::=  * 
ANYTHING  ::  = 

OTHERS  :  :  = 


•AND*  |  'OR1  |  'NOT'  |  'CON* 

"  <  ANYT HING>  *  '  ' 

(  <digit>  |  sgaigpfM.iHi&T 


-  1 « t  «  (• 

i  «  .  <  «  .  • 

')  • 

•  ?  *  1 

'$•  ( 

'  1  *  j 

•a  *  | 

•X* 

|  ....  ] 

•  •  1 

l  •<•  i 

1  '.'  •♦• 

(  I  « 

DISPLAY  'DISPLAY'  <IDENTIFIER>  [<PARAMS>] 


PARAHS  :: 

LINE  : 

PIELD 

TEXT  : 

LOCATE  : 
POSITION  : 
ROW 

COL  : 

CREATE  : 
DEP.LINE  : 

DEF_ FIELD 
ATTRIBUTES 


a  «  («  r  <LINE>  ]  '  # '  [<FIELD>]  '  ,  ' 
[<TEXT>  ]  '  )  ' 


NUMBER 

NUMBER 

ANYTHING 

•LOCATE'  <ROH>  <COL> 
•POSIT*  <ROH>  <COL> 
NUMBER 
NUMBER 


a  •  CREATE  *  <IDENTIFIER>  <DEF_LINE>  **24  'END* 

*  (D<DEpf  FIELD?* “foRT  ^ BLANK 'N)0I,'InDL^NE'  '; 
;*  'DEP.FIBLD'  <IDENTIFIBR>  <ATTRIBUTES>  ';' 

..a  '  ('  <access  >  ]  */'  [  <backgr3dn6>]  '.' 

*  /wvfi  r*N  1  t  \  t 


LENGTH  : : 

value  :: 

ACCESS  :: 

FOREGROUND 

BACKGROUND 

VIDEO  : 

UNDERLINE 

INTENSITY 

TYPE  : 


•<  '  J  W  W  - 

<TYPE>  ]  ')  * 

»  NUMBER 
»  ANYTHING 
=  *  R/O*  l  'R/N' 

DIGIT 

DIGIT 

*  'NORMAL'  I  'INVERSE' 

:  :«  'ON*  |  'OFF' 

:«  'BRIGHT*  I  'DIM' 

•«  'ALPHANOM*  |  'NUMBER*  \  'CHAR'  \  'STRING' 
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A££EH j£X  B 

BBS  COMMAND  LANGUAGE  USEE'S  MANUAL 

A.  INTRODUCTION 

The  BBS  Command  Language  (RSCL)  is  designed  to  create  micro¬ 
processor  shell  formats  from  within  user  designed  software 
programs.  Programs  written  in  the  language  will  interface 
with  the  display  module  to  output  data  in  the  specified 
screen  format.  Menus  are  utilized  to  facilitate  program 
entry  and  apprise  users  of  available  formatting  options.  The 
language  uses  an  interpreter,  written  in  "C" ,  to  execute  the 
programs. 

B.  LEXICAL  CONTENTIONS 

There  are  seven  types  of  tokens:  identifiers,  integers, 

strings,  arithmetic  operators,  logical  operators,  logical 
functions  and  others.  In  general  blanks,  tabs,  comments  and 
newlines  are  ignored  except  as  they  serve  to  separate 
tokens.  At  least  one  of  these  characters  is  required  to 
separate  otherwise  adjacent  identifiers.  The  language  does 
not  incorporate  any  reserved  words  in  the  grammar.  Each  of 
the  BSCL  statements  is  considered  a  keyword  when  used  at  the 
beginning  of  a  command  sequence,  however,  since  keywords  are 
not  treated  as  reserved  words  they  are  allowed  to  be 
assigned  as  identifiers  latter  in  a  command  line.  The  semi¬ 
colon  acts  as  a  statement  terminator. 

i .  afissaimogs 

Each  word  is  scanned  for  inclusion  in  one  of  the  seven  iden¬ 
tified  token  types.  The  tokens  are  then  processed  one  at  a 
time  through  the  CLI.  The  following  subsections  describe 
the  token  formats  in  detail. 
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a.  IDENTIFIERS 


Identifiers  nay  consist  of  alphanumeric  characters  and  the 
underscore  symbol.  The  first  character  must  be  alphabetic. 
It  is  optionally  followed  by  characters,  underscores  or 
digits.  Upper  or  lower  case  alphabetic  characters  are 
allowed  but  are  not  distinguished.  The  standard  convention 
of  not  allowing  an  identifier  to  terminate  with  an  under¬ 
score  applies.  Identifiers  have  a  maximum  length  of  ter 
characters  and  their  value  can  be  one  of  three  types:  char¬ 
acter,  string  or  integer. 

BIP  format: 

IDENTIFIER  :  <CH  ARACTER  >  <SUB_ID> 

SUB.ID  •_»  (  <CHA3ACTER>  |  <DIGIT>  )  <SOB_ID> 

b.  JOBBERS 

Numbers  are  formed  by  conca tinating  one  or  more  digits  onto 
a  digit.  Only  digits  are  used  to  form  numbers.  Numbers  are 
not  re- definable  data  types. 

BVP  format: 

NOHBER  < D I GI T >  |  <DIGIT>  <N0BBER> 

DIGIT  *0*  |*2* |*3* I' 4*  |*5*  |*6*  |*7*  |  •  8 1 1  •  9* 

C.  STRINGS 

Strings  are  any  ASCII  print  character  (s)  between  double 
quotation  marks  ("  ") .  The  language  reads  "this  is  a 

string"  as  a  3ingle  string. 

BIP  format: 

STRING  *  "*  <ANTTHING>' 

ANYTHING  (  <DI GIT> | <C HAR ACTER> | 

<ARITH— OPR>| <OTHERS>  <ANYTHING> 


d.  ARITHMETIC  OPERATORS 


Standard  arithmetic  operators  i.e.  "  ♦ " ,  "♦",  "/"  are 

implemented  within  the  language.  Unary  operations  are  not 
currently  supported  by  the  language. 

BIP  format: 

ARITH_OPR  ::=  | I •*' I*/' 

e.  LOGICAL  OPERATORS 

Alphabetic  type  characters  i.e.  "EQ",  "LT",  "3T",  "NE", 

"GE" ,  "LEM  are  used  to  perform  logical  operations.  The 
first  three  equate  to  equals,  less  then,  and  greater  then 
respectively.  The  last  three  equate  to  not  equal,  greater 
then  or  egual,  and  less  then  or  equal.  All  expressions  are 
required  to  be  parenthesized  i.e.  (A  GE  3)  or  (4  LT  9). 

BIP  format: 

LOG_OPR  » EQ* |  • LT*|  'GT •{  *  HE • | *GE* |  •  LE  • 

f.  LOGICAL  FUNCTIONS 

Logical  functions  also  use  alphabetic  type  characters  i.e. 
"AND",  "OR",  "NOT",  "CON”  to  perform  their  functions.  The 
"AMD",  function  returns  true  if  the  two  arguments  bracketing 
the  "AND"  are  both  true.  The  "OR"  function  returns  true  if 
either  of  the  bracketing  arguments  is  true.  The  "NOT"  func¬ 
tion  logically  complemnts  its  operand.  The  "CON"  function 
concatenates  a  string  onto  another  string.  Like  the  logical 
operators,  parentheses  are  required  in  logical  expressions 
i.e.  ((Z  GE  n  AND  <M  LT  W) )  where  Z,  T,  M,  and  W  are  vari¬ 
ables  or  expressions  which  evaluate  to  comparible  data 
types. 

BIP  format: 

LOG_PUNC  ' AND*  |  'OR'J  • NOT' |  'CON' 
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g.  OTHERS 


The  others  token  type  is  a  collection  of  the  remaining  stan¬ 
dard  ASCII  print  character  types  i.  e.  "(",  ")", 

"#",  etc.  These  characters  represent  their  normal  meaning 
except  where  their  meaning  is  negated  i.e.  "GT"  replaces  ">" 
sign  in  the  grammar  convention. 

BMP  format: 

OTHERS  *'  1  I*  ('  I  •)  ■  I'l  •  I  • :  •  |  I  *1  •  •  I  •  # 1  |  •  S  1 1  •»' 

I  |  •  *  I  *  <  *  l*>*l  * .  '  I  *  *  *  I  *  ' 


C.  DECLARATIONS 

The  language  does  not  provide  for  any  variable  pre¬ 
declaration.  New  variables  on  the  LHS  or  RHS ,  if  reading  in 
data  from  the  CRT  (screen)  or  a  file,  will  be  assigned  the 
same  data  type  as  the  recieved  data  automatically.  Type 
conversions  are  not  performed  in  the  language. 

D.  S INTI I 

The  BNP  (Backus  Naur  Form)  syntax  structure  for  the  grammar 
is  provided  in  Appendix  A. 

E.  P  BOG  BAH  STBOCTOBB 

All  programs  written  in  the  RSCL  are  comprised  of  three 
parts;  a  header,  statements  to  execute  and  a  trailer. 
Pigure  B.  1  shows  the  format  of  a  simple  program. 

This  sample  demonstrates  the  overall  program  structure.  The 
first  line,  " program  sample"  is  the  program  header.  Note, 
that  it  does  not  include  a  semicolon.  A  semicolon  is  a 
statement  terminator  (a  semicolon  is  required  at  the  and  of 
every  statement) .  The  complete  statement  is  "program  test 
<executable  statements>  end.;". 


*  77W  7  \v  ^  ;  ■, 


"  L.,  ,. ..,,  „  ,, 


'.*  ■'»  "*  »T 


program  sample 


put  crt  skip  "Enter  a  value  for  the  loop  count."; 

Jet  crt  a; 
oon  a 

if  (  a  eq  2) 
then 

put  crt  "The  value  of  a  is  "  a; 
else 

get  testfile.dat  b  ; 

g^t  crt  skip  "When  a  =  2,  b  *  "  b; 

endloop; 

end. 


Figure  B. 1  Sample  command  Language  Prograe. 


The  second  through  twelfth  lines  are  the  executable  state¬ 
ments.  They  perform  the  actual  processing.  The  trailer  is 
"end. 

The  indentation  and  structured  appearance  is  optional. 
The  CLI  ignores  blanks  and  carriage  returns.  Therefore, 
multiple  statements  can  be  placed  on  a  single  line  and  a 
single  statement  can  be  split  over  several  lines.  Figure 
B. 2  shows  two  legal  ways  to  write  the  same  statements. 


While  no  one  should  write  a  program  in  the  second 
format,  if  t he  code  needs  to  be  packed,  any  format  is  accep¬ 
table  so  long  as  variable  names  are  not  split  between  lines. 
In  that  case  they  will  be  treated  as  two  separate  variables. 

Now,  knowing  the  general  structure  of  an  RSCL  program, 
each  of  the  ten  individual  statements  are  discussed  in  the 
following  sections.  Each  statement's  function  and  format, 
the  constraints  on  its  use  and  tha  error  messages  which  can 
occur  with  their  probable  sause(s)  are  described. 

1 .  The  i£T  Statement 

The  LET  statement  is  used  to  perform  arithmetic  operations 
and  to  assign  values  to  variables.  When  performing  arith¬ 
metic,  the  expression  on  the  RHS  must  be  contained  within 
parenthesis.  The  value  of  that  expression  will  then  be 
assigned  to  the  variable  on  the  LHS.  If  no  arithmetic  is 
required,  the  RHS  may  contain  either  an  integer,  a  string  or 
a  variable.  In  that  case,  either  the  integer  value,  the 
actual  string  or  the  value  of  the  variable  will  be  assigned 
to  the  variable  on  the  LHS. 

If  the  variable  on  the  LHS  is  not  defined,  it  is 
dynamically  defined  according  to  the  type  and  value  of  the 
RHS.  If  the  variable(s)  on  the  RHS  are  not  defined,  an 
error  message  is  printed.  If  both  variables  are  defined, 
their  types  are  compared  to  ensure  that  the  assignment  is 
correct. 


a.  Format 

A  LET  statement  must  be  in  the  form: 

'let'  <identifier>  '*'  (  <expression>  |  <identitier> 

|  <number>  |  <string>  ) 

Where  the  word  "LET"  is  the  keyword  and  must  be  the  first 
word  in  the  statement.  "LET"  is  followed  by  an  identifier 
which  is  treated  as  the  LHS  of  the  statement  and  will  be  the 
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recipient  of  the  assignment.  Next,  the  equals  sign,  "=",  is 
expected.  This  is  used  to  separate  the  LHS  from  the  RHS  and 
to  show  the  direction  of  assignment.  It  should  not  be 
confused  with  the  standard  relational  operator  "="  which 
means  equality.  (  In  RSCL  equality  is  represented  by  the 
string  "eg") .  The  RHS  may  contain  only  one  of  either  an 

expression,  an  identifier,  a  number  or  a  string.  Upon 
execution  of  the  let  statement,  the  value  of  the  RHS  is 
assigned  to  the  variable  on  the  LHS. 

The  expression  on  the  RHS  may  be  a  valid  arith¬ 
metic  expression  containing  variables  and  the  arithmetic 
operators  of  "  ♦  «-•«,  "* "  and  "/".  These  operators  hold 

their  standard  meaning  of  addition,  subtraction,  multiplica¬ 
tion  and  division.  The  precedence  of  operations  may  be 
either  implied  or  explicitly  declared  by  the  use  of  paren¬ 
theses.  The  implied  precedence  is  equals  "/"  and 
equals  While  and  "/"  are  the  higher  precedence  and 

are  always  performed  before  "♦'*  or  Operations  of  equal 

precedence  are  performed  left  to  right.  Figure  B.  3  illus¬ 
trates  the  LET  statement  format. 

b.  Error  Types 

The  error  messages  associated  with  the  LET  statement  are: 
MESSAGE: 

AN  IDENTIFIER  was  expected,  but  ssss  was  found 

at  1111. 

EXPLAIITIOI: 

"ssss"  is  the  token  that  was  found  prior  to  the 
point  ”1111"  in  the  input  line.  Check  the  syntax  ,of  the 
statement  containing  this  line. 

HESS  AGE: 

*  was  expected,  but  ssss  was  found  at  1111. 
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EXPLAIATIOI 


"ssss"  is  the  token  that  was  found  prior  to  the 
point  "1111"  in  the  input  line.  An  "="  was  expected  desig¬ 
nating  the  direction  of  the  value  assignment  in  the  let 
statement. 

MESSAGE: 

AS  ARITHMETIC  EXPRESSION  was  expected,  but  ssss 
was  found  at  1111. 

EXPLAIATIOI: 

"ssss"  is  the  token  that  was  found  prior  to  the 
point  "1111 "  in  the  input  line.  The  RHS  of  the  let  state- 
aent  did  not  contain  a  valid  arithmetic  expression.  Most 
likely  a  matching  parenthesis  was  omitted. 

MESSAGE: 

AN  ARITHMETIC  OPERATOR  was  expected,  but  ssss 
was  found  at  1111. 

EXPLA1ATI0H: 

"ssss"  is  the  token  that  was  found  prior  to  the 
point  "1111"  in  the  input  line.  The  RHS  of  the  LET  state¬ 
ment  did  not  contain  a  valid  arithmetic  operator  between  two 
identifiers. 

MESSAGE: 

Undefined  identifier,  ssss  at  pppp  in  line:  1111 

EXPLAIATIOM: 

"ssss"  is  the  token  that  was  found  prior  to  the 
point  "pppp"  in  the  input  line  "1111".  An  identifier  in  the 
BBS  of  the  let  statement  did  not  have  a  value.  All  identi¬ 
fiers  must  be  set  before  they  can  be  referenced. 

MESSAGE: 

Data  type  mismatch.  A  string  type  was  expected 
at  pppp  in  line:  1111 

EXPLAIATIOM: 

The  LHS  of  the  LET  statement  was  of  type  string 
but  the  RHS  was  not. 


let  a  *  7; 

Assigns  the  integer  value  7  to  the  variable 
"a".  If  ’’a”  is  undefined  it  will  also  dynamically 
declare  variable  "a"  type  "I"  for  integer. 

let  a  *  b; 

Assigns  the  value  cf  "b"  to  the  variable  "  a'* . 

If  "6"  does  not  have  a  value  then  an  error  is 
called.  If  both  "a"  and  "b»  have  values  then 
a  type  check  is  made.  Otherwise,  "a"  is 
dynamically  assigned  the  data  type  of  "b". 

let  a  »  ( (b  ♦  c)  *  7)  ; 

Assigns  to  th9  variable  "a"  the  resulting  value  of 
the  fiHS  expression.  If  "a”  is  an  undefined  variable 
then  it  will  dynamically  receive  the  same  data 
type  as  the  expression  result  or  if  "a”  is  defined 
the  LHS  and  B HS  types  are  compared. 

let  a  *  "this  is  a  test"; 

Assigns  the  string,  "this  is  a  test",  to  the 
variable  "a".  If  "a"  is  undefined  then  it  will  be 
dynamically  assigned  data  type  "S"  in  the  symbol 
table  or  variable  "a"  is  compared  for  data  type 
"S"  string. 


Figare  B.3  SAHPLE  LET  STATEMENTS, 
c.  Osage  Constraints 

A  maximum  of  20  operations  may  be  nested  in  the  arithmetic 
expression.  The  type  checking  is  performed  based  on  the 
type  of  the  right-most  variable  in  the  BHS. 

2 .  Tfrq  Statement 

The  GET  statement  is  used  to  read  data  into  the  program  from 
some  external  device  and  assign  that  data  value  to  a  program 
variable. 

a.  Format 


A  GET  statement  must  be  in  the  fora: 
'get*  <device>  <list> 


Hhere  the  word  "GET"  is  the  keyword  and  must  be 
the  first  word  in  the  statement.  ••Get*'  is  followed  by  a 
device.  This  device  may  be  either  ••CRT"  for  the  user's 
console  or  the  name  of  a  file.  Anything  which  is  net  "CRT" 
is  considered  a  file.  The  name  of  the  file  may  optionally 
be  prefaced  by  a  disk  drive  designator  and/or  suffixed  by  a 
file  type.  The  total  file  name  follows  the  file  naming 
conventions  established  for  the  CP/a  operating  system. 

Following  the  device  is  a  list  of  identifiers 
which  will  receive  the  values  as  read  from  the  input  device. 
If  the  identifiers  are  already  defined,  the  data  will  be 
read  according  to  the  defined  type.  otherwise,  the  identi¬ 
fier's  type  will  be  set  depending  on  the  type  of  the  data 
which  is  read.  Figure  B.  4  illustrates  the  GET  statement 
format. 


get  CRT  a  (b,c. .  . )  ; 

Reads  the  next  terminal  input  and  assigns  it  to 
the  variable  "a".  If  th9  variable  "a"  is  undefined 
it  will  dynamically  assign  the  input's  data  type 
to  "a",  otherwise,  it  will  perform  a  type  check 
on  "a".  Hoce  then  one  input  can  be  read  from  the 
terminal  during  a  get  statement.  Type  checking 
is  done  on  eacn  receiving  variable. 

get  <FH>  a  (b  ,c.  . .) ; 

Opens  the  designated  data  file  <FN>  and  reads  the 
data  in  sequential  order.  The  receiving  variable  (s) 
are  either  dynamically  assigned  the  input's  data 
type  (undeclared)  or  a  type  check  is  performed. 


Figure  B.4  SAHPLB  GET  STATEBEBTS 


b.  Error  Types 

The  error  messages  associated  with  the  GET  stateaent  are: 

B2SSAG2: 

DEVICE  *  CBT’  or  a  file  aaae  was  expected,  but 
ssss  was  found  at  1111. 

EXPLAIATIOI: 

"ssss"  is  the  token  that  was  found  prior  to  the 
point  "1111*'  in  the  input  line.  The  word  'get'  must  be 
followed  by  the  aaae  of  the  device  from  which  to  read  the 
data. 

■ESSAGE: 

Filename  —  (<FN>  [.<FT>])  --  was  expected,  but 
ssss  was  found  at  1111. 

EXPLAIATIOI: 

"ssss"  is  the  token  that  was  found  prior  to  the 
point  "1111"  in  the  input  line.  k  file  naee  eay  be  up  to  8 
characters  long  and  optionally  prefaced  by  a  drive  desig¬ 
nator  (one  character  followed  by  a  colon)  . 

Filetype  —  (<FH>  [.<FT>])  --  was  expected,  but 
ssss  was  found  at  1111. 

2XPL  A I ATIG1 : 

"ssss"  is  the  token  that  was  found  prior  to  the 
point  "1111"  in  the  input  line.  k  file  type  may  be  up  to  3 
characters  long  and  sust  be  prefacad  by  a  period.  k  file 
type  only  appears  after  a  valid  file  name. 

BESS AGE: 

Unable  to  open  file  -  check  <FN>  is  capitalized 

EXPLAIATIOI: 

The  file  designated  in  the  GET  statement  does 
not  exist.  Check  the  spelling  of  the  file  name.  Be  sure  to 
watch  for  discrepancies  in  capitalization. 
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BBS SAGE: 


Cannot  read  from  the  list  device  at  pppp  in 

line:  1111 
EXPLANATION: 

"PPPP"  is  the  point  in  the  input  line  "1111"  at 
which  the  error  occurred.  A  devica  type  of  "LST"  is  illegal 
for  the  GET  statement. 

c.  Osage  Constraints 

There  are  no  usage  constraints  in  the  GET  statement. 

3.  £22  §ta.tgiaat 

The  POT  statement  is  used  to  ouput  data  from  a  program  vari¬ 
able  to  some  external  device. 

a.  Format 

A  POT  statement  must  be  in  the  fora: 

'put*  <device>  ['skip*]  <list> 

Share  the  word  "PUT"  is  the  keyword  and  must  be  the  first 
word  in  the  statement.  "POT"  is  followed  by  a  device.  This 
device  may  be  either  "CRT"  for  the  user's  console,  "LST"  for 
the  line  printer  or  the  name  of  a  file.  Anything  which  is 
not  "CRT"  or  "LST"  is  considered  a  file.  The  name  of  the 
file  may  optionally  be  prefacad  by  a  disk  drive  designator 
and/or  suffixed  by  a  file  type.  Tha  total  file  name  follows 
the  file  naming  conventions  established  for  the  CP/M  oper¬ 
ating  system. 

flie  device  is  optionally  followed  by  the  word 
'skip'.  If  included,  this  will  cause  a  newline  control  code 
to  be  transmitted  to  the  output  device.  Note,  the  skip  is 
only  done  once  per  statement. 

Next  is  a  list  of  identifiers  and/or  character 
strings.  Figure  B.5  illustrates  tha  POT  statement  format. 
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put  CRT  a  (b ,  c. . . )  ; 

Displays  on  the  CRT  (screen)  the  value  of  the 
variable  Ma".  Multiple  displays  (b,c...)  are  allowed. 

put  CRT  SKIP  (a,b...)  ; 

Slcips  a  line  prior  to  displaying  the  variable  data. 
The  skip  ±3  perforated  only  once  prior  to  displaying 
ing  the  variable(s)  value  (s)  . 

put  LST  a  (b,c. . . )  ; 

Toggles  the  printer  on  (providing  it  is  turned  on) 
ana  transfers  the  variable  (s)  value  (s)  to  it. 

put  LST  <FN>; 

Toggles  the  printer  on  (providing  it  is  turned  on) 
ana  transfers  the  data  contained  in  the  designated 
file  <FN>. 

put  <FN>  a  (b,c. . ; 

Opens  the  designated  file  <FN>  and  stores  the 
variably  (si  value  in  the  file.  The  file  <FN>  is 
automatically  closed  upon  stateaant  termination. 


Figure  B.5  SIMPLE  POT  STATEHEHTS. 
b.  Error  Types 

The  error  messages  associated  with  the  POT  statement  are: 
MESSAGE: 

DEVICE  "CRT**  or  "LST"  or  a  file  name  was 
expected,  but  ssss  was  found  at  1111. 

EXPLANATION: 

•*ssssH  is  the  token  that  was  found  prior  to  the 
point  "1111"  in  the  input  line.  The  word  ‘put’  must  be 
followed  by  the  name  of  the  devica  on  which  the  data  is  to 
be  written. 

MESSAGE: 

Filename  —  (<FN>  [.<FT>])  —  was  expected,  but 
ssss  was  found  at  1111. 
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EXPLAIATIOH: 

Mgsss"  is  the  token  that  was  found  prior  to  the 
point  "1111"  in  the  input  line.  A  file  name  may  be  up  to  8 
characters  long  and  optionally  prafaced  by  a  drive  desig¬ 
nator  (one  letter  followed  by  a  colon). 

BBS SAGE: 

Filetype  —  (<FN>  [.<FT>])  —  was  expected,  but 
ssss  was  found  at  1111. 

EXPLAIATIOH: 

"ssss"  is  the  token  that  was  found  prior  to  the 
point  "1111"  in  the  input  line.  A  file  type  may  be  up  to  3 
characters  long  and  must  be  prefaced  by  a  period.  A  file 
type  only  appears  after  a  valid  file  name. 

HESS  AGE: 

Undefined  identifier,  ssss  at  pppp  in  line:  1111 

EXPLAIATIOH: 

"3sss"  is  the  token  that  was  found  prior  to  the 
point  "pppp"  in  the  input  line  "1111".  A  value  must  be 
defined  for  any  variable  before  it  can  be  output.  3e  sure 
that  all  designated  variables  are  sst  to  some  value  before 
they  are  referenced. 

c.  Osage  Constraints 

If  the  data  is  being  put  to  a  file,  that  file  is  opened  in 
append  mode.  Therefore,  if  a  new  file  is  desired,  the  user 
■ust  ensure  that  any  previous  file  with  that  name  is  erased 
prior  to  executing  the  PUT  statement. 

4.  Ilia  2  statement 

The  IF  statement  executes  a  set  of  statements  based  on  the 
logical  value  of  the  IF  clause.  If  this  value  is  true  (not 
0)  ,  the  THEM  group  of  statements  is  executed.  If  the  IF 
clause  value  is  false  (0),  the  ELSE  group  of  statements  is 
executed.  The  ELSE  group  is  optional.  If  it  does  not  exist 


and  the  IF  clause  value  is  false,  the  entire  IF  statement  is 
ignored. 

a.  Format 

In  IF  statement  must  be  of  the  form: 

*if'  <logical  expression>  'then1  <statement s> 

Where  the  word  "IF"  is  the  keyword  and  must  be  the  first 
word  in  the  statement.  "IF"  is  followed  by  a  logical 
expression.  This  expression  must  be  contained  within  paren¬ 
theses  and  may  be  any  valid  combination  of  logical  operators 
(eg.  It,  gt,  ne,  le,  ge)  ,  logical  functions  (and,  or,  not) 
variables  and  numbers.  Precedence  of  operations  is  deter¬ 
mined  solely  on  the  bases  of  parenthetical  grouping. 

The  logical  expression  must  be  followed  by  the 
word  "THEN"  and  the  group  of  statements  which  will  be 
executed  if  the  logical  expression  is  true.  This  group  of 
statements  terminates  either  with  the  word  "ELSE"  or  the 
word  "EHDIF". 

If  the  logical  expression  is  false,  the  THEN 
group  of  statements  is  skipped  and  the  ELSE  group  is 
executed  (if  it  exists) .  The  IF  statement  terminates  upon 
detection  of  the  word  "ENDIF; ".  Figure  B.6,  illustrates  the 
IF  statement  format. 

b.  Error  Types 

The  error  messages  associated  with  the  IF  statement  are: 

BESSAGE: 

An  IF  statement  must  have  a  logical  expression 
at  pppp  in  line:  1111 

BXPLA1ATI0I: 

••pppp*  is  the  point  in  the  input  line  "1111"  at 
which  a  logical  expression  was  expected.  Check  for  matching 
oarentheses. 


if  <logical  expression  then 
<statement  s> 
else 

<statements> 
endif ; 

The  logical  expression  portion  is  tasted  first.  If 
true,  the  statements  in  the  THEM  portion  (any  SSCL 
statements)  are  executed  in  ordar.  The  sta tenants 
contained  in  the  ELSE  (optional)  portion  ara 
executed  only  whep  the  I?  condition  returns  false. 
The  IF  statement  is  terminated  by  an  ENDIF. 


MESSAGE: 


Figure  B.6  SAMPLE  IF  STATEHEHT. 


THEN  was  expected  but  ssss  was  found  at  1111. 


SXPLAIATI01: 

"ssss"  is  the  token  that  was  found  prior  to  the 
point  "pppp".  The  THEN  clause  is  mandatory  in  an  IF  state¬ 
ment.  Be  sure  that  all  designated  variables  are  set  before 
they  are  referenced. 


MESSAGE: 


ENDIF  was  expected  but  ssss  was  found  at  1111. 


EXPLAIATIOI: 

"ssss"  is  the  token  that  was  found  prior  to  the 
point  "pppp".  An  IF  statement  must  terminate  with  the  word 
"ENDIF". 


c.  Osage  Constraints 

There  are  no  usage  constraints  for  an  IF  statement. 

5.  I&2E.  Statement 

The  LOOP  statement  repeats  a  set  of  statements  a  specified 
number  of  times.  Any  number  of  repetitions  may  be  specified 
via  either  a  number  constant  or  a  variable  entry. 


a.  Format 


A  LOOP  statement  oust  be  in  the  form: 

'loop*  (  <identifier>  |  <number>  )  <statem3nts>  'endloop;* 
Where  the  word  "LOOP"  is  the  keyword  and  must  be  the  first 
word  in  the  statement.  "LOOP"  is  followed  by  either  a 
number  or  an  identifier  which  gives  the  number  of  times  the 
loop  is  to  be  executed.  The  loop  checks  this  value  before 
execution.  If  the  loop  value  is  <=  0,  the  statements  in  the 
loop  are  skipped.  otherwise,  the  inner  statements  are 
repeated  until  the  loop  counter  reaches  0.  The  loop  counter 
cannot  be  changed  once  the  loop  has  begun  executing.  Even 
if  the  identifer  used  for  the  loop  counter  is  altered,  the 
loop  will  not  be  affected.  Figure  B.7  illustrates  the  LOOP 
statement  format. 


loop  a 

<statements> 

endloop; 

The  variable  "a"  contains  the  number  of 
iterations  that  the  statements  contained 
within  the  loop  will  be  executed.  Any 
combination  of  valid  BSCL  statements 
is  allowed. 

locp  7 

<stat9ments> 

endloop; 

The  only  difference  in  this  statement  is  the  loop 
counter  is  in  integer  form  vice  identifier  fora. 
The  loop  execution  sequence  is  not  altered. 


b.  Error  Types 


The  error  messages  associated  with  the  LOOP  statement  are: 
HESS AGS: 

Undefined  identifier,  ssss  at  pppp  in  line:  1111 

EXPLAIATIOM: 

"ssss"  is  the  token  that  was  found  prior  to  the 
point  "pppp"  in  the  input  line  "1111".  A  value  must  be 
defined  for  any  variable  before  it  can  be  used  as  a  loop 
counter.  Be  sure  that  all  designated  variables  are  set 
before  they  are  referenced. 

HESSAGE: 

An  integer  or  variable  loop  count  was  expected 
but  ssss  was  found  at  1111 

EXPLAIATIOI: 

"ssss"  is  the  token  that  was  found  prior  to  the 
point  "1111".  A  locp  counter  can  only  be  an  integer  or  an 
identifier. 

c.  Usage  Constraints 

Nested  loops  cannot  be  used. 

6 .  The  CASE  Statement 

The  CASE  statement  executes  a  set  of  statements  based  upon 
the  case  variable.  If  one  of  the  cases  matches  the  value  of 
the  case  variable  then  that  set  of  statements  is  executed. 
If  none  match,  then  the  OTHERWISE  set  of  statements  is 
executed. 


a.  Format 

The  CASE  statement  must  be  in  the  form: 

•case'  <identifier>  ':  '  case_num 

'otherwise:'  <statements>  'endcase' 
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Where  the  word  "CASE”  is  the  keyword  and  must  be  the  first, 
word  in  the  statement.  "Case"  is  followed  by  an  identifier 
and  a  colon.  This  is  the  case  variable.  Each  of  the  cases 
that  follow  begin  with  either  a  number  or  an  identifier 
followed  by  a  colon.  This  value  is  compared  with  the  value 
of  the  case  variable.  If  they  are  equal,  then  all  the 
statements  in  the  case  element  (up  to  the  next  case  number) 
are  executed.  If  no  case  number  matches  the  case  variable 
then  the  statements  in  the  otherwise  clause  are  executed. 
The  CASE  statement  is  terminated  with  the  word  "ENDCASE"  and 
a  semicolon.  Pigure  B.  8  illustrates  the  CASE  statement 
format. 


case  a: 

b:  <statements> 
c:  <statements> 

6:  <statements> 
otherwise 
endcase; 

The  case  statement  uses  a  variable  or  an  integer 
to  indicate  which  case  element  will  be  invoked. 
The  "a"  Represents  the  data  type  of  the  case 
element  index.  If  none  of  the  case  elements  are 
invoked  then  the  otherwise  case  element  is 
executed.  Any  valid  HSCL  statement  is  allowed. 


Figure  B.8  SAMPLE  CASE  STATEMENT. 


b.  Error  Types 

The  error  messages  associated  with  the  CASE  statement  are: 
MESSAGE: 

Undefined  identifier,  ssss  at  pppp  in  line:  1111 

EXPLA1ATIOM: 


"3sss"  is  the  token  that  was  found  prior  to  the 
point  "pppp”  in  the  input  line  "llll”.  A  value  must  be 


defined  for  any  variable  before  it  can  be  used  as  a  loop 
counter.  Be  sure  that  all  designated  varialbes  are  set 
before  they  are  referenced. 

MESSAGE: 

—  :  —  was  expected  but  ssss  was  found  at  pppp. 

EXPLABATIOB: 

"ssss”  is  the  token  that  was  found  prior  to  the 
point  ”pppp".  A  case  variable  must  be  followed  by  a  colon. 
MESSAGE: 

OTHERWISE  was  expected  but  ssss  was  found  at 

pppp. 

EXPLAMATIOI: 

"ssss"  is  the  token  that  was  found  prior  to  the 
point  Hpppp".  A  CASE  statement  must  include  an  OTHERWISE 
clause  to  handle  the  event  when  no  labled  case  value  was 
matched. 


c.  Osage  Constraints 

There  are  no  usage  constraints  for  the  case  statements. 

7.  The  CREATE  State men t 

The  create  function  was  not  coded  because  the  interface 
between  the  CLI  and  display  modules  is  unknown.  The  create 
module  was  designed  to  interface  with  a  commercial  produce. 
The  product  is  still  enroute  to  the  school.  when  coded  the 
create  nodule  will  assign  attribute  values  to  specified 
fields.  The  resulting  template  is  then  utilized  for  data 
display  through  the  display  module. 

8.  Th?  Stat enpnt 

The  display  function  was  intended  to  be  an  external  commer¬ 
cial  product  purchased  from  a  local  vendor.  Unfortunately, 
the  supply  system  was  uncooperative  and  the  product  never 
arrived.  As  designed,  display  manager  takes  the  output  data 


and  transposes  it  onto  the  requested  screen  shell  created  in 
the  create  nodule. 

F.  GEHEB1L  EBROB  Hi  MOLING 

The  system  and  syntax  error  handler  messages  are  formatted 
as  follows: 

(•**•*  SYNTAX  or  SYSTEH  EBBOB  *••*•») 

(EBBOR  HE  SSAGE  (S)  ) 

MESSAGE: 

Symbol  table  exceeded. 

EXPLAIATIOI: 

The  maximum  length  of  the  symbol  table  vas  exceeded,  too 
many  variables  in  the  program. 

BESSAGSS: 

Premature  end  of  input  encountered. 

EXPLAIATIOI: 

The  program  ended  without  a  proper  terminator  i.e.  END. 
Program  could  be  in  the  middle  of  a  command  when  the  input 
terminates. 

■ESSAGES: 

Unrecognized  character,  ssss  in  line:  1111. 

EXPLAIATIOI: 

"ssss",  a  non  ASCII  type  token,  was  encountered  prior  to 
the  point  "1111"  in  the  input  line. 

BESS AGES: 

String  length  exceeds  (132)  in  line  1111 

EXPLAIATIOI: 

The  token  prior  to  the  point  "1111 "  in  the  input  line 
exceeds  the  maximum  sring  length  of  (132). 

BESSAGBS: 

PBOGBAB  was  expected,  but  ssss  was  found  at  1111. 


BXPLABATIOl: 

Program's  must  start  with  tha  constant  "PROGRAM " 
followed  by  the  prograa  name. 

BBS SAGES: 

AM  IDENTIFIER  was  expected,  but  ssss  was  found  at  line 

mi. 

BXPLAIATIOl: 

This  could  have  several  meanings.  LHS's  of  let  state¬ 
ments  require  an  identifier  (variable).  Data  file  reads  also 
require  a  variable  to  receive  transfered  data. 

BESSAGES: 

END.  was  expected,  but  ssss  was  found  at  line  1111. 

BXPLABATIOl: 

An  input  following  a  statement  must  be  either  another 
statement  or  an  (END.). 

BESSAGES: 

Mo  legal  Command  Language  statement  was  found-  prior  to 
the  point  1111  in  the  input  line. 

EXPLABATIOBS: 

This  error  message  is  only  invoiced  during  the  first 
statement  following  the  prograa  name. 

BESSAGES: 

expected  at  ssss  in  line  1111. 

BXPLABATIOl: 

Semicolons  terminate  all  statements.  Check  the  statement 
at  the  indicated  line. 
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/*  R  6  S  Command  Lanouaqe 

* 

*  Last  ucdate:  22  Sep  1993 

* 

*  CONSTANT  DEFINITIONS  * 

*/ 

•define  debug  0 

•define  debugease  0 
•define  debuoqet  0 
•define  debualf  0 
•define  debuglet  0 
•define  debugloop  0 
•define  debuaout  0 
•define  debuastate  0 
•define  false  0 

•define  true  1 

•define  maxsym  25 
•define  devslz  15 
•define  llneslz  132 
•define  loop.lst.slz  10 
•define  strlngsiz  132 
•define  symslz  10 
•define  optorslz  20 
•define  oprandslz  40 
•define  EOFILE  '  # 

•define  newline  '0 
•define  ld.token  1 
•define  str. token  2 
•define  Int.token  3 
•define  arlth.op.token  4 
•define  log.op.token  5 
•define  log.f unc.token  6 
•define  other.token  7 


/********************************************************************* 

*  GLOBAL  VARIABLE  DEFINITIONS  * 

*/ 

FILE  'output,  'Input,  'source,  'loop. file; 

char  LOOP. FILE £201 ,  'loopptr;  /'  file  name  for  loop  statements'/ 

char  sev.devtdevslz] ;  /*  device  name  for  put  &  get  */ 

cher  out.devCdevsiz] t  /*  device  name  for  put  statement*/ 

char  get.devCdevslz] ;  /*  deviee  name  for  get  statement'/ 

cher  symtypei  /*  type  of  symbol  I  or  C  */ 

cher  symldCsymslz] ,  'ldptr?  /*  actual  symbol  char  strina  */ 

cher  stringCstrlrqslzJ ,  *sptr»  /*  character  string  */ 

cher  tokenCsymsiz] ,  'tptr*  /*  actual  token  char  string  */ 

eher  line tlinesiz) ,  *lptr?  /*  current  Input  line  »/ 

cher  loop.lst tloop.lst.slz] tlinesiz] !/»statements  repeated  In  loop'/ 


lnt  loop.cnt? 


/*  loop  statement  counter,  used  */ 
/*  by  getllre  to  repeat  statemnt*/ 
lnt  token-type?  /*  type  of  token  */ 

lnt  symval?  /*  value  of  symbol  */ 

int  numsym?  /*  number  of  symbols  active  */ 

lnt  exp. result?  /*  result  of  arith  expressions  */ 

lnt  opr. value;  /*  precedence  values  of  arith. oo*/ 


struct  < 

char  ldtsymslzJ,  esidptr? 
lnt  value? 
char  type? 

>  symbol Cmaxsym] ,  *symptr 


/*  symbol  table 
/*  symbol  name 

/*  symbol  value 

/*  symbol  type  (I  or  C) 


*/ 

*/ 

*/ 

*/ 
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*  This  Is  the  main  routine  for  the  Command  Language  Interpreter, 

*  It  calls  "statements*'  to  prccess  all  other  statements. 

*  If  main  completes  successfully  the  intercreter  exits. 

* 

*  Functions  used:  errorCl 1/12/14/51 ) ,  next,  statements 

*  Global  used:  token,  token. type 

*  Constants  used:  id. token 

* 

*  Author:  Dennis  J.  Ritaldato 

*  Last  update:  22  Sep  1983 
*/ 

•Include  <stdlo.h> 

•include  "global. interp" 
main  () 

{ 

LOOP. FILE  CO]  a  »"; 

Strcpy(LOOP.FILE,"LOCPZZZZ"); 

looo.cnt  *  0?  /*  init  loop  counter  */ 

nuirsym  a  o:  /*  init  symbol  table  */ 

source  a  fooen("RSCL","r");  /*  open  source  file  for  */ 

/*  command  language  program  */ 

nextO; 

if  (  strcmp(token, "PROGRAM")  ) 
error  (11); 
next() ? 

if  (  token.type  la  id. token  ) 
error  (12); 
nextO; 

if  (  1  statementsO  ) 
error  (51); 

if  (  strcmp( token , "END" )  ) 
error  (14); 
nextO ; 

if  (token(O)  la  *.*) 
error  (14); 
exitO; 


/* 

*  Statements  cnecks  the  token  to  determine  if  It  is  a  reserved  word 

*  lndicatlnq  the  beginning  of  a  command  language  statement. 

*  If  found  the  correscondlno  functionis  called  to  process  the 

*  statement.  Then  statement  calls  Itself  to  look  for  more  statements 

*  and  returns  true, 

*  Functions  used:  case. statement ,  create#  display,  error(53), 

*  If. statement ,  let. statement #  loop. statement ,  next, 

*  put.statement  qet. statement, 

*  Globals  used:  token 

*  Constants  used:  none 

* 

*  Author:  Dennis  J.  Rltaldato 

*  Last  update:  19  sec  1983 

*/ 

•include  <stdlo.h> 

•include  "global. interp" 
statements  () 

< 

•if  debugstate 

printf ("Entered  statements  with  token  of  %s,0, token); 
tendlf 

if  (  istremp(token,  "LET")  ) 

{  nextO; 

let.statement £ ) ; 

> 

else  If  (  IstrempCtcken,  "IF")  ) 

<  nextO; 
lf.statement ( ) ; 

> 

else  if  (  istrempctoken,  "PUT")  ) 

<  nextO; 

PUt.statementO ; 

> 

else  if  (  !strcmp(token,  "GET")  ) 

{  nextO; 
get.statemento ; 

} 

else  if  (  !strcmp(token,  "LOOP")  ) 

(  nextO; 
loop.statementO ; 

> 

else  If  (  istrempctoken,  "CASE")  ) 

<  nextO; 
ease.statemento ; 

} 

else  if  (  istrempctoken,  ";")  ) 

C  nextO; 

•if  debug 

printf ("  comment  found, 0); 
tendlf 

while  C  strempetoken,  ";")  ) 
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rextc) ; 

) 

else  it  (  IstrcircctoKen,  "DISPLAY")  ) 
{  nextOj 
display  O ; 

) 

else  if  (  ! strcirp (token ,  "CREATE")  ) 

<  nextO; 


/* 

*  The  scanner  scans  the  input  stream  for  tokens  which  are  either: 

*  identifiers  -  alpha talphanum  I  . 

*  integers  -  diqit : integers 

*  strings  -  anything  except  ; 

*  logical  ops  -  EO  |  LT  I  GT  I  NE  I  LE  !  GE 

*  arith  ops  *  *  I  •  I  ♦  I  / 

*  logical  funcs  -  AND  I  OR  I  NOT  I  CON 

*  others  -  any  other  ASCII  character 

* 

*  Functions  used:  error(4),  qetlire 

*  Glofcals  used:  line,  lptr,  log. opr,  log.fune,  loop.cnt,  loop. list, 

*  loop. 1st. ent,  loot. 1st. ptr , 

*  sptr,  string,  token,  token. type,  tDtr 

*  Constants  used:  arlth.op.token ,  id. token,  int. token,  symslz, 

*  log. op. token ,  other. token,  str. token, 

*  log.func. token 

*  Author:  Dennis  Rltaldato 

*  Last  update:  22  Sep  1993 
*/ 

•include  <ctyoe.h> 

•include  <stdio.h> 

•include  "global, interp" 
next  () 

< 

int  i  a  0; 

tptr  *  token; 

*tptr  »  null; 
token.type  a  o; 

/*  if  end  of  line  */ 

if  (  (*lDtr  a*  NULL)  II  {*lptr  a*  NEWLINE)  ) 

getlineC);  /*  oet  new  line  */ 

while  (  (»lptr  ■«  *  *)  II  ( llsascii (*lptr)  )  )/*  skip  blanks  */ 

if  (  c*lptr  «»  NULL)  II  (*lptr  a«  NEWLINE)  )  /*  if  end  of  line  */ 
qetlineO;  /*  get  new  line  */ 

else 
♦♦lptr; 

> 

if  (  isalpha(*lptr)  )  /*  is  token  an  identifier?  */ 

<  for  C  1  «  o»  lsalpha(*lptr) 1 1  lsdlglt C*lPtr)  II  (*lptr  aa  '.');  ) 

if  (  !♦♦  <  symsiz  ) 

*tptr++  a  uppert  lptr++  ); 

•tptr  a  NULL; 

if  (  ilog.oprO  u  llog.funco  ) 
token.type  a  id. token; 
return; 

> 

else  if  (  isdigit(*lptr )  )  /*  is  token  an  integer?  */ 

<  while  (  isdigit (*lctr)  ) 

•tptr++  ■  *lptr++; 


•tptr  *  NULL; 
token-tyoe  s  int. token; 
return; 

> 

switch  (*lptr)  < 
ease 

sptr  *  string; 
token. type  a  str. token; 

♦♦Iptr; 

for  Ciao;  (*lptr  1*  +*lptr) 

<  if  (  *lptr  aa  null  ) 
getlineC); 

if  (!♦♦  <  stringsiz) 

*sptr++  a  *iptr; 
else 

error(5); 

> 

♦♦lptr; 

•sptr  *  null; 
return; 

ease  case 

opr.value  *  1; 

token-type  a  arith. op. token; 
♦tptr-M-  «  *iptr++; 

•totr  a  null; 

return; 

ease  '••;  ease  V'; 
oor.value  a  j; 

token-tyoe  a  arith. op.toker ; 


/*  is  token  a  char  string?  */ 


/*  it  end  of  line  */ 
/*  get  new  line  */ 


/*  bypass  second 


/*  is  token  an  arithmetic  op?*/ 


•totr-M- 

•tptr 

return; 


a  *iptr++; 
a  null; 


case 

'('; 

ease 

case 

ease 

'] ': 

case 

case 

case 

' : ' : 

ease 

ease 

0 10 1 

ease 

'd'j 

ease 

'«*: 

case 

's': 

case 

ease 

a  a  #  • 
e 

ease 

'S'! 

ease 

ease 

*<'; 

ease 

*>'; 

case 

ease 

ease 

ease 

case 

't ': 

ease 

'S': 

ease 

ease 

»«»• 

e 

ease 

*#*• 

• 

token-type  a  other.token; 

•tptrte  a  Mptr-M-; 

•tptr  a  null; 
return; 
default; 

✓*error(4);*/ 

#lf  debug 

printf ("-•Unrecognized  char  %c  with  value  %d  found, 0, *iptr,*lptr) ; 
•endif 

•lptre+; 
ne*tO ; 
return; 

)  /*  end  switch  */ 
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Getline  reads  the  next  lire  either  from  the  input  stream 
if  the  loop  counter, "loop. crt"  is  0  or  from  the  loop  statement 
list,  "looo.lst"  if  the  loop  counter  is  Greater  t*an  o.  it 
decrements  the  loop  counter  each  time  a  line  is  read. 

Each  line  read,  regardless  of  source  is  placed  into  an  array  of 
characters  called  "line". 

If  an  EOFILE  is  encountered  an  error  message  is  printed  out  and 
the  orograro  terminates. 

Otherwise,  the  line  pointer  is  reset  to  the  beginning  of  the 
line  and  the  function  returns. 

Functions  used:  error(3) 

Gicbals  used:  line,  lptr,  lccp.cnt,  loop. list,  loop. 1st. cnt , 
loop. 1st. ptr 

Constants  used:  arith.oe.token ,  id. token,  int. token, 

log.fune.token 


9 

< 


Author:  Dennis  Ritaldato 
Last  update:  22  Sep  1993 

/ 

tlineO 
int  1; 


/*  begin  getline 


*/ 


tor  (i»0;  i  <  linesiz:  i++)  /*  clear  line  buffer  */ 

lined]  »  NULL : 


if  (looo.cnt  >  0)  /*  read  from  the  loop  list?  */ 

< 

if  (  fqetsCline, linesiz, loop. file)  =a  eqfile  ) 

<  fcloseCloop.f lie] ; 

If  C  —  loop.cnt  >  0  ) 

(  looo.flle  »  fopen  (L00P.FILE,  "r"); 
f gets Cline,linesiz,loop.f lie) : 

) 

} 

lptr  «  line: 
return: 

> 

else  if  f  source  1*  NULL  ) 

<  lfC  fgetsdine, linesiz, source)  ■*  EOFILE  )/*read  from  file  RSCL*/ 

error(3) : 

•if  debug 

prlntf ("--Source  line  read.O): 
fendlf 
> 

else 

<  if  (  gets(llne)  *■  EOFILE  )  /*  read  from  the  terminal  */ 

error(3): 

Ilf  debug 

printfC"— CRT  line  read.O): 
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tendlf 

> 

tif  debug 

printf ("--The  new  line  is:  %sO,llne): 
tendlf 

lptr  a  line; 
return: 
v 


/*  end  getline 


*  Upper  converts  a  lower  case  ASCII  character  to  upper  case  ASCII, 

*  Any  characters  which  are  not  lower  case  ASCII  are  ignored. 

* 

*  Author:  Dennis  J,  Ritaldato 

*  Last  update:  14  Sep  1983 

*/ 

upper(e) 
char  *c t 

( 

if  (  ( 'a'  <■  *c)  &&  <*c  <*  'z')  ) 

*c  ■  *c  ♦  # A #  -  *a#? 
return(*c) t 


/*  if  lowercase  */ 

/*  convert  to  uppercase*/ 


/* 

*  log.opr  examines  the  current  token  to  determine  if  it  is  a 

*  logical  operator. 

*  If  so.  it  sets  the  token.type  appropriately, 

* 

*  Author*  Dennis  J,  Rltaldato 

*  Last  update:  15  Sep  1983 
*/ 

log.oprO  /*  begin  loq.opr  ♦/ 

< 

if  (  strlen(token)  la  2) 
return(false) ; 
tptr  a  token? 
switch(*tptr)  < 
ease  'E#: 

if  (*+4tPtr  la  '0') 
return(false) ; 
break; 
case  #N'j 

if  (♦♦♦tptr  la  'E#) 
return(false) ; 
break; 

ease  #G#:  ease  #L#* 

if  (  (•♦♦tptr  la  'T')  6&  c*++tptr  la  'E')  ) 
return(false) ; 
break; 
default: 

returnCfalse); 

> 

token.type  a  icq. op. token ; 
returnCtrue); 

*/ 


} 


/*  end  log.opr 


/* 

*  Log.func  examines  the  current  token  to  determine  if  it  is  a 

*  logical  function  operator. 

*  If  so,  it  sets  the  token.type  appropriately. 

* 

*  Author!  Dennis  J.  Rltaldato 

*  Last  update:  14  Sep  1983 
*/ 

log.funcC)  /*  begin  log.func 

< 

if  (  C  lstrcmp(token,"AND"))  II  (lstrcmp(token,*,OR")) 

II  C!strcmp(token,"NOT"))  It  ( I strcmp(token, "CCN") )  ) 

<  token.type  a  log.f unc.token t 
retum(true)  > 

> 

return (false) ; 

>  /*  end  log.func 


/* 

*  This  procedure  adds  a  nee  symbol  to  the  symbol  table. 

*  increments  numsym 

*  creates  a  nee  symbol  table  entry  with  the  values  contained  in 

*  symld,  symval  and  symtype 

*  return 

*  Author)  Oennls  J.  Ritaldato 

*  Last  update)  13  Sep  1983 
*/ 

•Include  <stdloah> 

•Include  "global. interp" 
addsymO 
< 

lnt  1; 

if  (numsym  >  maxsym) 
error(2); 

symptr  ■  asymool CnumsymeeJ ; 
for  Ci«0)  symidCili*'  *)  ++1)  < 
symptr  •>  Id C 1 3  a  symidCilJ 
symotr  ->  value  «  symval) 
symotr  ->  type  *  symtype)  > 

•If  debug 

printf ("ADDSYM  entered.  Numsym  *  %dO,numsym)j 
•endlf 
return) 
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*  This  procedure  assigns  the  value  contained  in  symval  to  tfe 

*  symbol  indicated  by  symptr. 

*  Author*  Dennis  J.  Ritaldato 

*  Last  update*  13  Sep  1983 
*/ 

•include  <stdio.h> 

•include  "global. inter?" 
setvalueO 
< 

symptr  ->  value  ■  symval; 
return* 


;■  p«  p> 


/* 

*  LOOKUP  searches  the  symbol  table  for  a  match  on  symld  and 

*  symbol. Id,  If  found# 

*  set  symptr,  symval  and  symtype  from  tne  contents  of  the 

*  symbol  table,  return  true 

*  else 

*  symptr,  symval  and  symtype  remain  unchanqed 

*  returns  false 

«  Authori  Dennis  d.  Rtialdato 

*  Last  update!  13  Sep  1983 

*/ 

•include  <stdio.h> 

•include  "global. interp" 
loekupO 
< 

int  1; 

for  (symptr  »  SsymboltO];  symptr  <*  (symbol  ♦  numsym)?  mmsymptr) 
for  (i»0;  symptr*>i<S  (13  ■*  symldtil?  m+1) 
if  (svnidCil  »«"')< 
symval  *  symctr->value? 
symtype  •  symptrotypej 
return  (true};  > 
return  (false}! 
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/ 


♦This  function,  assignes  values  to  variables.  The  LHS  (left  hand  side) 

♦  variable  must  be  an  identifier.  The  only  exception  is  when  a  string 

♦  is  assiqned  then  the  LHS  variable  is  the  global  array  string.  RHS's 

♦  can  be  either  an  expression,  integer  or  a  declared  identifier  with 

♦  a  value  of  the  ldentiflei  stored  in  the  symbol  table.  Expressions. 

♦  of  any  length  are  accepted.  Unary  minus  operations  are  not 

♦  supported  in  this  version. 

♦ 

*  Functions  used:  addsym,error( 12/18/55/57) ,  expression,  lookup,  next 

*  setvalue 

*  Globals  used:  exp. result, 

*  Constants  used:  id. token, 

* 

*  Author:  David  J.  smania 

*  Last  Update  22  Sep  83 
*/ 

•include  <stdio.h> 

•Include  "global . interp" 

char  operator Coptorsizl ; 
char  savetype: 
int  operand Coprandsiz) ; 
int  a, b,m,n, marker, last.prec; 

let. statement  C) 

{ 

char  savetokentsymsiz] : 
int  sav. value, addf lag; 

•if  debug 
printf ("LET.3TATEMENT  entered.O); 

•andif 

/I*******************  EVALUATE  LEFT  HAND  SIDE  *********************«***/ 


if  (token.type  !*  id.token)  /*  Check  for  identifier  */ 

< 

error  C12);  /*  Error  token  not  identifier  */ 

return; 

> 

else 

strcpyCsavetoken, token) ;  /*  Save  token  name  */ 

next  (); 

if  Cstrcmp(token,"«")  «■  0)  /*  Check  for  »  token  */ 

next  (); 

else 

< 

error(l8);  /*  Missing  'a*  operator  */ 

return; 

> 


/*  Entering  let  statement  */ 

/*  Declare  local  variables  */ 


symid,  symtype,  symval,  token,  token.type 
int. token 


/*  Link  standard  I/C  */ 

/*  link  all  program  constants  */ 

/*  Declare  let. statement  variables  */ 


/************************  RHS  CHECK  ****************************»<****/ 
/* 

*  The  expression  function  first  determines  if  the  RHS  is  an 

*  expression.  If  so,  then  it  evaluates  the  expression  and 

*  returns  the  result  to  exp.result.  Error  checKino  is  performed 

*  throuhqout  the  function, 

*/ 

if  (expression  ())  /*  Checlc  for  2nd  aro  =  expression  */ 

sav.value  *  exp.result;  /*  Exp  result  saved  */ 

else 

if  (token.type  as  id. token) 

< 

strepy(symid, token) ;  /*  Load  symid  for  lookup  */ 

if  (lookup  ()) 

< 

sav.value  a  symvai;  /*  Save  variable  value  */ 

savetype  a  symtyce?  /*  Save  variable  type  */ 

} 

else 

error  (55)i  /*  Variable  not  in  symbol  table  */ 

next  (); 

> 

else 

if  (token.type  as  int.teken) 

{ 

savetype  a  *l#; 

sav.value  a  atol(token);  /♦  Save  integer  value  */ 

next  Os 

> 

else 

if  (token.type  as  str.token) 

( 

symtyoe  a  #s'r 
next  (); 

s trcpy( symid, sa vet oken ) ? 
if  (1  lookup  (}) 

< 

symval  a  o » 
addsym  ()i 
return! 

> 

if  (symtype  as  #s#) 
returni 
error  ( 37 ) » 
return; 

> 

else 

< 

error(24);  /*  Not  exp,  string,  id,  int  */ 

return; 
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/************************  STRCPY  CHECK  ******************************/ 

strcpy(symid#savetoken) ;  /*  Load  symid  for  lookup  */ 

if  (lookuo  O) 

if  (savetype  a*  syirtype) 

< 

symval  a  sav. value; 

setvalue  O;  /*  Assign  values  to  symbol  table  variables*/ 

> 

else 

error  (57);  /*  Variable  not  in  symbol  table  */ 

else 

< 

symval  a  sav.value; 
symtype  a  savetype; 
addsym  (); 

> 


/*  Add  a  new  variable  to  symbol  table*/ 


/********************  EXPRESSION  FUNCTION  **********$**********•****/ 
/* 

*  EXPRESSION  determines  If  the  token  is  a  valid  arithmetic 

*  expression.  An  arithmetic  expression  is  defined  as  a  term 

*  optionally  followed  by  a  arithmetic  operator  and  a  subexpression. 

*  A  term  is  either  an  expression,  an  identifier,  a  number  or  a 

*  string.  A  subexpresion  is  a  term  optionally  followed  by  an 

*  operator  and  a  subexpression. 

*  If  a  valid  expression  is  found,  it's  value  is  stored  in  the 

*  variable  "exp. result"  and  true  is  returned.  Otherwise  false  is 

*  returned. 

* 

*  Functions  used:  error(22/50) ,  lookup,  next,  cop,  pushopratot, 

*  pushidoperand ,  set.prec 

*  Globals  used:  exp.result,  symid,  symtyoe,  symval,  token,  token.type 

*  Constants  used:  arith. op. token ,  Id. token,  lnt. token 

* 

*  Author:  David  J.  Smania 

*  Last  Update  22  Sep  83 


expression  O 

< 

m  *  Or 
n  *  0; 

last.prec  a  0; 

if  ((strcmo(token,"(")  *=  0))  /*  Check  for  lead  of  exp  */ 

< 

pushoprator  Of  /*  Push  *(*  on  stack  */ 

next  Of 

if  (token.type  **  int.token)  /*  Check  for  integer  RHS  */ 

savetype  *  "I#? 
else 

if  (token.type  as  id.token)  /*  Check  for  identifier  RHS  */ 

< 

strcpy (sym id, token)  / 
if  (lookup  O) 
savetype  ■  symtyee; 
else 

savetype  a  'C'i 

> 

/********************  LOOP  THROUGH  RHS  ****************************«*/ 

while  (token(O)  Ja  #;*j  /*  Loop  until  is  read  */ 

< 

if  (stremp(token,"(")  *»  0) 

< 

pushoprator  Of 
nextO; 
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if  (strcmp(token,")")  ==  0)  /*  Enter  pop  routines  */ 

< 

pop  ()? 
set.pree  (); 
next  (); 

> 

else 

if  (token.type  »*  id.token)  /*  Lookup  identifiers  */ 

< 

strepycsymid, token) ; 
if  ( !  lookup  ()) 
error  (55); 
else 
{ 

pushidoperand  (); 
next  (); 

> 

) 

else 

if  (token.type  um  int.token)  /*  Push  integer  tokens  */ 

( 

syravel  «  atoi(token); 
pushintoperand  (); 
next  (); 

> 

else 

/*  Check  operator  precedence  */ 
if  (token.type  ■»  arith.op. token) 
if  (eheek.prt  ()) 

( 

pushoprator  (); 
next  (); 

> 

else 

{ 

pop  ()| 
set.pree  C); 

> 

else 

error  (21); 


/***********«**********  END  WHILE  LOOP  ***********************/ 

if  ((operator CO]  ■  '(#)  &&  (operatorci)  «  ')')) 

( 


exp. result  «  operand (-«ro) ; 
symval  *  exp.result; 
return  (true); 


error  (22); 

> 

else 

return  (false); 


> 


/*«**********«*****  PUSH  INTEGER  FUNCTION  **♦**********♦************/ 
/* 

*  This  function  pushes  the  ineommino  integer  token  onto  the  stack 

*  operand  Cm] . 

* 

*  Author:  David  J.  Smania 

*  Last  Updata  25  September  83 

*/ 

pushlntoperand  () 

{ 

operandCm]  a  atoi(token); 

♦em? 

> 

/MMM*M***nMMM*  PUSH  IDENTIFIER  FUNCTION  ♦*♦**♦*»***♦♦******/ 
/* 

*  This  function  pushes  the  identifier  value  operands  onto  the 

*  stack  operandCm]. 

* 

*  Author:  David  J.  Smania 

*  Last  Updata  24  September  83 
*/ 

pushldoperand  (] 

( 

operandCm]  a  symval; 

♦♦mi 

> 

/*M*M***mm*«M»  push  OPERATOR  FUNCTION  *****»*******************/ 
/* 

*  This  function  pushes  the  lneommlng  operator  onto  the  stack 

*  operatorCn], 

* 

*  Author:  David  0.  Smania 

*  Last  Updata  23  September  83 

*/ 

pushoprator  () 

< 

operator  r,i]  a  tokenCO]; 

♦♦n: 

y 
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/,*****************  CHECK  PRIORITY  FUNCTION  l**********************/ 

/*  Check  the  ineemina  operator  prececdence  with  the  existing  hiohest 

*  precedence,  last.prec,  value.  Modify  if  ineommino  is  qr.ater. 

* 

*  Author:  David  J.  Smaniat 

*  Last  Update  23  September  83 

*/ 


cheek. pri  () 

< 

if  (opr.value  >  last.prec) 

< 

last.prec  *  opr.value; 
marker  *  n? 
return  (true); 

} 

else 

if  (opr.value  s»  last.prec) 
retum(true) ; 

else 

return  (false); 


v.v.v.v.v.v.>>  ■ 


/I**********************  POP  FUNCTION  *******************************/ 
/* 

*  Poc  the  operators  and  operands  off  their  respective  stacfcs 

*  according  to  the  token  read, 

*  Author:  David  J.  Smania 

*  Last  Update  23  September  83 

*/ 

pop  O 

< 

int  l,done; 

done  a  0; 

— n ; 

if  (stremp(token,")")  =a  0)  /*  Pop  until  '('  Is  found  */ 


while  CoperatorCn]  t  =  '(') 

< 

••m  t 

a  a  operand  Cm]; 

b  a  operand  Cm); 
check.token  (); 

> 

else 

while  (n  >a  marker)  /*  Pop  until  lower  precedence  */ 

< 

— m: 

a  a  operand  [ml J 
•«m  | 

b  a  operand  Cm] ; 
check. token  (); 

> 

return: 


> 


/****«***♦*********«****  SET  PRECEDENCE  ♦*********♦******************/ 
/* 

*  Set  the  precedence  variable  last.prec  to  the  highest  rrecederce 

*  operator  in  the  stack  operator E n 1  • 

*  Author:  David  J.  Smania 

*  Last  Update  23  September  83 
*/ 

set.prec  () 

< 

int  l,done: 


done  *  0; 

♦♦n: 

eperatorCn]  a  tokenioi: 

for  CiaO:  ((i<an)  &&  ('done)  &&  (operatortil 
{ 

if  ((operator Cil  a*  '♦')  l  l  (operator CiJ  «a 
( 

last.prec  *  It 
done  a  true: 
marker  *  i; 

> 

else 

last.prec  a  o; 

> 

return: 

> 


*)')):  i++) 
*)) 


/**e******************  PERFORM  ARITHMETIC  »»*****♦»»*****♦*♦***»****/ 
/* 

*  Perform  arithmetic  operations  based  on  operatorCn]  found.  Store 

*  results  in  operandtmj, 

* 

*  Author:  David  J.  Smanla 

*  Last  Update  23  September  83 
*/ 


eheck.token  () 

< 

If  (ooeratortnJ  **  *♦') 

( 

ooerandCm)  a  (a  +  b): 
♦♦m: 

••n; 

) 

else 

if  (operatortnl  »« 

< 

operandlml  a  (b  -  a}: 
♦♦m: 


if  (cperatorin]  « 

< 

operand!!*]  *  (a  *  t); 

— n? 

> 

•lie 

if  Coperatortnl  ==  '/•) 

< 

operand!!*]  *  (b  /  a)? 

♦+e; 

— n; 

> 

return; 

) 

/*********************  END  LET. STATEMENT  ************♦***************/ 


/* 

*  This  procedure  receives  data  from  either  the  screen  (CRT)  or  a 

*  resident  file.  The  function  first  checks  for  the  user's  reouested 

*  display  device  then  responds  te  the  user's  data  requests.  Two 

*  types  of  data  input  requests  are  available  to  the  user:  from  a 

*  file  on  the  user's  disks  or  a  variable  stored  in  the  symble  table, 

*  Global  variable  sav.dev  stores  the  user's  device  reouest. 

* 

*  Function  used:  next,  error(20/56) ,  device,  id. list,  addsyrr 

*  Glcbals  used;  sav.dev,  get. dev,  string,  sptr,  symtype,  sytrval, 

input 

*  Constants  used:  null,  strlngsl2 

* 

*  Author:  David  J,  Smanla 

*  Last  Update  22  Sep  83 
♦  / 


iinelude  <stdio.h>  /*  Link  standard  I/O  */ 
•include  <etype.h>  /*  Link  Integer  check  routine  */ 
iinelude  "global. interp"  /*  Link  all  program  canstants  */ 


char  savetype; 
lnt  sav.val; 

get. statement  () 

( 

lnt  bad; 
fif  debug 

or lnt f ( "GET. statement  entered, 0); 
iendif 

if  (i  devleeO) 

< 

error(20) ; 
return; 

> 

strepy (get. dev, sav.dev) ; 
if  (strcmp(get.dev,"CRT")  **0) 

{  while  ( id. list  ()  ) 

< 

if  (savetype  ■■  'S') 
gets  (  string  ); 
else  if  (savetype  ==  'I') 

< 

scanf  ("  %d" ,6symval) ; 
setvalue  (); 

> 

else  if  (savetvpe  sa  *c') 

( 

symval  a  getcharO; 
setvalue  (): 

} 

else 


/*  Declare  local  variables  */ 

/*  Entering  get  statement  */ 

/*  Declare  get  variables  */ 

/*  Check  for  device  token  */ 

/*  Invalid  device  type  */ 


/*  Save  device  name  in  get. dev*/ 
/*  Loop  until  id. list  is  empty*/ 
/*  Check  saved  token  type  */ 


/*  Identifier  is  unknown  */ 


gets(strino) ; 
sptr  »  string; 

for  (badafalse;  (  (*sptr  !*  null)  &&  (*sptr  1=  '  ') 

&&  (Ibad)  );  ++sptr) 

If  (  l  isdlgit (*sptr) )  /*  Is  Input  a  digit 

bad  a  true; 

If  ( !bad) 

<  symtype  a  *i'; 

symval  a  atol (string) ; 

> 

else 

(  If  (strlen(strlnq)  as  n 
<  symtype  a  #c#; 
symval  a  token(O) ; 

> 

else 

symtype  a  #s#; 

> 

addsymO ; 

> 

next  ();  /*  bypass  Input  variable 

>  /*  end  of  while  loop 

} 

else 

if  (strcmp(get.dev,"LST")  »*0) 

C  error (56) ;  /*  Invalid  device  input 

return(false) ; 

} 

else 

(  Input  a  fopen(qet.dev,"r");  /*  Open  file  to  read  onl* 

while  (Id. list  ()  )  /*  loop  until  ld.llst  is 

< 

If  (  savetype  a»  #s#) 

fqets  (  string, strlngslz, input  ); 
else  If  (savetype  *■  "IO 
<  fscanf  (Input,"  %d" ,tsymval) ; 
setvalueO; 

> 

else  If  (savetype  aw  #cO 
{  fscanf  (Input,"  %c" ,4symval) ; 
setvalueO; 

} 

else  /*  identifier  is  unknown 

( 

fscanf  (Input,"  %s", string); 
sptr  a  string; 

for  (badafalse;  (  (*sptr  I*  NULL)  &&  (*sptr  la  #  #) 

&&  (Ibad)  );  ♦♦sptr) 

if  (  1  isdlgit(Mptr))  /»  Is  input  a  digit? 


/»  invalid  device  input 


/*  Open  file  to  read  only  */ 

/*  loop  until  ld.llst  is  empty  */ 
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a 


bad  s  true; 

If  ( Ibad) 

<  syrntype  8  #I 

synval  3  atoi(strlnq) ; 

> 

else 

<  it  (strien(strlng)  38  u 
<  symtype  *  *C*t 

symval  3  tokenCO); 

> 

else 

sywtype  ■  #S'; 

> 

addsymC ) ; 

> 

next  (); 


> 


) 


/*  bypass  input  variable 
/*  end  of  while  loop 
/*  end  of  file  processing 


Ilf  debugget 

prlntfCAt  end  of  GET,  token  3  %s0, token); 

•endlf 

return; 

)  /*  end  get.statement 


3/ 

*/ 

*/ 


»/ 


/************************  ID. LIST  FUNCTION  I******#******************/ 
/* 

*  The  id.list  function  checks  if  the  input  variable  is  already 

*  declared  in  the  symbol  table.  If  true,  it  saves  the  data  type  for 

*  type  checking,  A  data  tyee  of  *l)#  undefined  is  set  otherwise. 

* 

*  Function  used!  lookup 

*  Globals  used!  symtype,  token 

*  Constants  used!  id.token 

* 

*  Author!  David  J.  Smania 

*  Last  update:  22  Sep.,  1983 
*/ 

id.list  <) 

( 

if  (token.type  1«  id.token) 
returnCfalse) ; 

strcpyCsymid, token) j  /*  Place  token  in  symid  for  lookup  check*/ 

if  (  lookup  ()) 

savetype  «  symtype;  /*  Save  token  type  for  latter  comparison*/ 

else 

savetype  »  #u 
return  (true): 


/****************  END  GET. STATEMENT  a********************************/ 


PUT.STATEMENT  outputs  to  either  the  screen  (CRT) 
or  the  printer  (LSD  data  stored  In  a  variable  a 
string  or  a  file.  The  function  first  checks  for  the 
appropriate  display  "device"  then  responds  to  the 
users  data  requests.  Two  types  of  data  requests 
are  available:  a  variable  stored  in  the  symbol  table; 
or  a  string.  Global  variables  put. dev,  symval  and 
savetype  store  the  device  name,  the  token  value  and 
token  type  respectively. 

Functions  used:  next,  error(25),  list,  device, 

Globals  used:  outcut,  put. dev,  sav.dev,  string, 
token,  token. type 
Constants  used:  none 


Author:  David  J.  Smania 
Last  Update  22  Sep  03 


•include  <stdlo.h>  /*  standard  I/c  link  */ 

•Include  "global. interp"  /*  Link  all  program  canstants  */ 


char  savetype;  /*  Declare  local  variables  */ 

int  sav.val; 


put.statement  ()  /*  Entering  put  case  statement  */ 

< 

•if  debug 

pr int f ("PUT.STATEMENT  entered. 0) ; 
lendlf 

if  (1  deviceO)  /*  Check  for  device  token  */ 

{ 

error(25);  /*  Invalid  device  type  */ 

return; 

> 

strcpy(out. dev, sav.dev) ;  /*  save  device  name  */ 

If  <strcmp(put.dev,"CRT")  *»0) 

{  if  (  !strcmp(token,"SKlP")  )/*  Skip  a  line  */ 

<  prlntf("0); 

nextO;  /*  bypass  skip  */ 

> 

while  (list  ())  /*  Loop  until  list  is  terminated*/ 

< 

•if  debugput 

printf("-»List  returned  true  with  token  a  %s0, token); 

•endif 

if  (savetype  «  *S#)  /*  Checks  for  token  type  */ 

puts(strlng); 

else 

if  (savetype  ««  #I#) 
printf("%d  ", sav.val); 


else 

printf("%c  ",sav.val); 
next  (); 

>  /*  end  while  list  */ 

>  /*  end  if  CRT  */ 

else 

if.  (stremp(put.dev, "LST")  **0) 
while  (list  ()) 

( 

printf ("toggling  printerO); 
next  (); 

> 

else 

< 

/*  Open  file  with  #a#  attribute*/ 
output  s  f open(put.dev, "a") ; 

•if  debugput 

printf ("Opening  new  file  %s0 ,put«dev) ; 

•endlf 

if  (  !strcmp(token,"SKIP")  )/*  Skip  a  line  in  the  file  */ 

<  printf("0); 

nextO;  /*  bypass  skip  */ 

> 

while  (list  ())  /*  Loop  until  list  empty  */ 

( 

if  (savetype  *■  #S')  /*  Checks  for  token  type  */ 

f puts (string, output) ; 
else 

if  (savetype  *»  #I#) 

fprintf (output, "%d  ".sav.val); 
else 

fprintf (output, "%c  ",sav.val): 
next  (); 

> 

fclose(output) ;  /*  Close  data  file  */ 

> 

•if  debugput 

prlntf("At  end  of  put,  token  *  %s0, token); 

•endlf 

return; 

> 


/t*t«**********f*****LIST  FUNCTION*************************/ 
/* 

*  The  list  function  checks  for  the  output  token  supplied  by 

*  the  user.  The  corresponding  token  data  values  are  stored 

*  appropriately  for  later  comparison. 

* 

*  Functions  usedt  next,  error(SS),  lookup 

*  Glofcals  used}  string,  syirld,  symval,  symtype,  token 

*  Constants  used:  id. token,  int. token,  str. token 

« 

*  Author:  David  J.  Smania 

*  Last  Update  22  Sep  83 
*/ 


list  C) 

< 

if  Ctoken.type  **  int. token) 

< 

sav.val  *  atoi(token);  /*  Save  token  value  */ 

savetype  ■  /*  Save  token  type  */ 

return  (true): 

> 

if  Ctoken.type  ■*  id.token) 

< 

/*  Place  token  in  symid  for  lookup  check  */ 
s trepyCsymld, token ) ; 
if  (  lookup  ()) 

< 

/*  Save  token  type  for  later  comparrison  */ 
savetype  «  syirtyoe; 

sav.val  a  symval;  /*  Save  variable  value  */ 

return  (true): 

} 

error  (55):  /*  Unidentified  variable  */ 

return  (false); 

> 

if  Ctoken.type  ■■  str. token) 

< 

savetype  a  *s#; 
return  (true); 

> 

return  (false);  /*  Error  no  match 

>  /*  end  list 


*/ 

*/ 


/* ********** ******END  PUT.STATEME NT ********************* *************/ 
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/* 

*  DEVICE  determines  if  the  current  token  Is  a  valid 

*  I/C  device  name,  A  valid  device  Is  defined  as  either 

*  "CRT"  for  the  user's  console,  "1ST"  for  the  line  printer 

*  or  a  filename.  The  file  name  is  structured  aceordinq 

*  to  the  file  namlna  conventions  ef  the  CPM  operating 

*  system.  That  Is,  a  name  optionally  creceeded  by  a  one 

*  character  disk  drive  designator  with  a  colon  and 

*  optionally  followed  by  a  period  with  a  three  character 

*  file  type, 

*  If  a  valid  device  is  found,  it  is  stored  in  the 

*  variable  "sav.dev"  and  true  is  returned,  otherwise, 

*  false  is  returned. 

* 

*  Functions  used:  next,  error(26/30) 

*  Globals  used:  sav.dev,  token,  token. type 

*  Constants  used:  id.token 

* 

*  Author:  David  J.  Smania 

*  Last  Update  22  Sep  83 
V 

•Include  <stdlo,h> 

•Include  "global.interp”  /*  Link  all  program  canstants  */ 

/****************«** *»CEVICE  FUNCTION **********************/ 

device  O 

< 

•If  debug 

prlntf ("DEVICE  entered. 0): 

•endlf 

If  (token.type  J»  id.token) 
return  (false): 

If  ((strcmp(token,"CRT")  0)  II  (strcmp( token, "LST")  «0)) 

( 

•if  debugput 

prlntf ("--device  «  %s0, token); 

•endlf 

strcpy(sav.dev, token) ;  /*  Save  display  type  */ 

next  ():  /*  bypass  CRT  I  LST  »/ 

return  (true); 

> 

strcpy (sav.dev, token ) ; 

next  ();  /♦  bypass  fname  I  drive  */ 

If  (strcmp(token,":")  **0) 

( 

street (sav.dev, token) ; 

next  ();  /*  bypass  :  */ 

If  (token.type  i«  id.token) 
return  (false); 

«trcat(sav.dev, token) ; 
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next  O?  /*  bypass  fname 

} 

if  CstrcmpCtoieen,1’,")  =»0) 

( 

strcatCsav.dev,  toicen) ; 
next  Of  /*  bypass  . 

if  (token. type  is  Id. token) 
return  (false)i 
s treat (sav.de v, token) ; 

next  ();  /*  bypass  ftype 

> 

return  (true); 


/*  IF  STATEMENT  executes  a  set  of  statements  based  on  the 

*  logical  value  of  the  the  lF*clause.  If  this  value  is 

*  true  (not  0),  the  THEN-group  of  statements  is  executed. 

*  If  the  IF«clause  value  is  false  (0),  the  ELSE-orouD  of 

*  statements  is  executed. 

*  The  EL5E»qroup  is  optional.  If  it  does  not  does  not 

*  exist,  the  entire  IF  statement  is  skipped. 

* 

*  Functions  used:  next,  error(16/17/27/54),  statements 

*  Globals  used:  token,  token. type,  symid,  symval 

*  Constants  used:  symsiz,  leg. op. token,  loo. func. token 

* 

*  Author:  Dennis  J.  Ritaldato 

*  Last  update:  22  Sep  1983 
*/ 

•include  <stdio.h> 

•include  "global. interp" 
lnt  log.result  ■  0: 
int  term  a  o; 
lnt  sub  a  o: 

•if  debuglf 
lnt  level  a  o; 

•endlf 

if. statement  () 

< 

•  If  debuq 

printf ("IF.STATEMENT  entered. 0): 

•  endlf 

if  (!  log-expC)  3 

<  error(54); 
return: 

> 

•if  debuglf 

printf ("—log-result  at  level  %d  is  %d. o, level, log.result) ; 
•endlf 

if  (log-result) 

<  if  (  strcmp(token,"THEN")  ) 

<  error(i6): 

return: 

> 

•if  debuglf 

printf  ("—THEN  found. 0): 

•endlf 


nextO : 

/♦ 

bypass  THEN 

*/ 

statementsO : 

/* 

execute  then  clause 

*/ 

/* 

skip  else  clause 

*/ 

while  (  stremp(token. 

"ENDIF") 

)  next(); 

> 

else 

/*  skip  then  clause  */ 

<  while  (  strcmp(token,  "ELSE" )  )  nextU; 

•If  debuglf 
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printf ELSE  found, 
iendif 

nextO; 
statements ( ) ; 

} 

if  (  stremp(toKen, " 
{  error(l7); 
return; 

> 

next( ) ; 
return; 


0); 


ENDIF")  ) 


/*  bypass  ELSE 
/*  execute  else  clause 

/*  bypass  ENDIF 
/*  end  if. statement 


/a 

*  LOG-EXP  determines  If  the  current  token  is  a  logical 

*  expression,  A  logical  expression  is  defined  as  a 

*  logical  term,  optionally  followed  by  both  a  logical 

*  operator  and  a  logical  subexpression.  The  entire 

*  logical  exoresslon  must  be  enelesed  in  parentheses. 

*  If  a  lealcal  expression  is  found,  it's  value  is 
a  stored  in  the  variable  "log-result"  and  true  is 

*  returned.  Otherwise,  false  Is  returned, 
a 

a  Author:  Dennis  J.  Rltaldato 
a  Last  update:  22  Sep  1983 
a/ 

log-exp () 

< 

lnt  lhs  a  o.  rhs  a  o; 
char  operator (symsiz) ; 

•If  debuglf 

prlntf ("Entered  loo-exp. 0): 

•endlf 

If  (stremp(token,"(")  ) 
return(false): 

nextO:  /*  bypass  "£"  »/ 

•if  debuglf 

prlntf  ("——Left  paren  found  for  level  %d.  ",ievel++); 
prlntf("  New  token  Is  %s0. token); 

•endlf 

If  (  !  log-termf)  ) 
return(false) ; 

•If  debuglf 

prlntf ("--—In  log-exp,  log-term  returned  %d  ".term); 

prlntf("  with  token  As. 0, token): 

prlntf ("•— and  token-type  of  %d.O .token-type) : 

•endlf 

lhs  ■  term: 

If  (  (token-type  as  log-op.tcken) 

II  (token-type  as  log.fune-token)  ) 

<  strcpyCoperator .token) : 

nextO:  /•  bypass  operator  ♦/ 

•If  debuglf 

prlntf ("••—Logical  expreesslon  operator.  %s,  found. 0, operator) ; 
•endlf 

If  (  1  sub.logO  ) 
return(false); 
rhs  a  sub: 

log-result  a  computedhs. operator, rhs); 

•If  debuglf 

prlntf  ("-—Compute  returned  %d,o. log-result); 

•endlf 

if  £  istrcmp(token,")")  ) 

(  nextO;  /a  bypass  ")"  */ 


Ilf  debuglf 

printf ( "--Right  paren  for  level  %d  compound  expression. 0, level) ; 

prlntf ("— with  next  token  of  ts .0 , token) ; 

lendlf 

return(true) t 

> 

else  /*  matching  right  paren  not  found  */ 

<  error(2-7)j 
return(faise) ; 

> 

> 

else  if  (  !strcmp( token,")")  ) 

<  log.result  a  lhs; 

nextO*  /*  bypass  *)*  */ 

return(true) t 

> 

else  /*  matching  right  paren  not  found  */ 

error (27) t 
return(falsa)  i 

*/ 


> 


/*  end  log.exp 


/* 

*  SUB. LOG  determines  if  the  current  token  is  a  logical 

*  subexpression,  a  sub  expression  Is  defined  as  a 

*  logical  term,  ootlonally  followed  by  a  logical  operator 

*  followed  by  either  a  logical  subexpression  or  a 

*  logical  expression. 

*  If  a  logical  subexpression  Is  found,  it's  value  is 

*  stored  In  the  variable  "sub"  and  true  is  returned. 

*  Otherwise,  false  Is  returned, 

*/ 

sub. log() 

( 

Int  lhs  *  0,  rhs  a  0; 
char  operator [symslz] ; 

•if  debuglf 

prlntf ("Entered  sub.log.O); 

•endlf 

If  C  l  log.termo  ) 
return(false) ; 
lhs  •  term 

If  (  (token. type  1 ■  log.op.tcken) 

(token. type  i  ■  log.f unc.token)  ) 

<  sub  a  lhs } 
return(true) ; 

> 

strepy (operator, token); 

next ( ) ;  /*  bypass  operator 

If  (  sub.logO  ) 

<  rhs  a  sub> 

sub  a  eompute(lhs, operator, rhs); 

•If  debuolf 

prlntf ("••-•In  sub-log,  sub.log  returned  %d.0,sub); 

•endlf 

return  (true); 

> 

If  (  log.expn  ) 

<  rhs  a  log.result; 

•If  debuglf 

prlntf ("••-•In  sub.log,  log.exp  returned  %d.0,rhs); 

•endlf 

sub  «  eomoutedhs, operator, rhs) } 
return  (true); 

> 

return  (false); 

> 


/*  end  sub.log 


/*  LOG. TERM  determines  If  the  current  token  Is  e  term 
*lne  logical  expression.  A  term  Is  defined  as  a 

*  logical  expression,  an  Identifier  or  a  number. 

*  If  a  term  Is  found.  It's  value  Is  placed  In  the 

*  global  variable  "term"  and  true  Is  returned. 

*  Otherwise,  false  is  returned. 

*/ 

log-term ( ) 

< 

»lf  debuglf 

prlntf ("Entered  Log-term. 0)i 
fend if 

if  (  log.expO  ) 

<  term  a  log-result; 
return(true) ; 

> 

It  (token-type  as  id-token) 

<  strepyCsymid, token)  ? 
lookup!) ; 

term  •  symval; 

nextO;  /*  bypass  identifier 

term  a  symval; 

«lf  debuglf 

prlntf  ("•—Identifier  value  %d  was  found. 0.  term) ; 
tendlf 

return(true) ; 

> 

if  (token-type  sa  int-token) 

(  term  a  atol(token); 

nextO;  /*  bypass  integer 

ilf  debuglf 

prlntf ("••••Integer  value  %d  was  found. 0, term); 
tendlf 

return(true) ; 

> 

return(false) ; 

>  /*  end  loo-term 


/* 

*  COMPUTE  performs  Che  operation  specified  in  the 

*  parameter  "op"  and  returns  a  value  of  true  or  false, 
*/ 

compute (lhs, op, rhs) 
lnt  lhs ,  rhs,  fop; 
f 

•if  debugif 

prlntf ("Entered  compute  with  %d  %s  %d.0,ihs,oo,rhs) ; 
fendlf 

if  (  lstre»o(op, "EO")  ) 

<  if  Clhs  **  rhs) 

return(true) ; 
return(false) ; 

> 

if  (  !strcmp(op, *LT»)  ) 

<  if  (lhs  <  rhs) 

return(true) ; 
return(false) ; 

> 

if  (  istrcmptop^GT")  ) 

<  if  (lhs  >  rhs) 

return(true) ; 
returnCfalse) ; 

> 

if  (  l Streep (op, "ME")  ) 

<  if  (lhs  l*  rhs) 

return(true); 
return(talse) ; 

} 

if  (  tstrcmp(op,"LE")  ) 

<  if  (lhs  <*  rhs) 

return(true) ; 
return(false) ; 

> 

if  (  istrcmp(op,"GE")  ) 

(  if  (lhs  >*  rhs) 
return(true) ; 
return(false); 

> 

if  (  lstrcirp(op,,,AND")  ) 

<  if  (lhs  t  rhs) 

return(true) » 
returnCfalse) ; 

> 

if  (  !stremp(op,"OP")  ) 

<  if  (lhs  I  rhs) 

return(true) ; 
returnCfalse); 

> 

if  (  1 stremp (op, "NCT")  ) 
return(  !lhs  ); 
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12  (  i*tre«*p(op, "CCN") 
{  puts ( "CON  Is  not  yet 
return(felse) j 

> 


) 

lmpleirentedC ) ; 


/*  end  compute 


*/ 


*  CASE. statement  executes  a  set  of  statements  based 

*  upon  the  case  variable,  if  one  of  the  cases  matches 

*  the  value  of  the  case  variable,  that  set  of  statements 

*  is  executed.  If  none  match,  the  otherwise  set  of 

*  statements  is  executed. 

* 

*  Functions  used}  lookup,  next,  case.num, 

*  error (23/31/32/33/55) ,  statements 

*  Global*  usedi  token,  token. type,  symld,  symval 

*  Constants  used}  id. token,  lnt.tcken, 

* 

*  Author}  Dennis  J.  Rltaldato 
«  Last  update!  22  Sep  1983 
*/ 

•include  <stdlo,h> 

•include  "olobal.interp" 
lnt  caseval! 
case.statement  () 

< 

•if  debug 

prlntf("  case.statement  entered. O) 
tendif 

if  Ctoken.type  »•  ld.token) 

<  strcpy (symld, token) ;  /*  get  case  variable  */ 

if  (  l  lookupO  )  /*  and  save  its  value  */ 

<  error(55);  /*  undefined  variable  */ 

return! 

> 

caseval  *  symval! 

> 

else  if  Ctoken.type  ■«  lnt.token) 
caseval  «  atoi(token); 

else 

(  error(23);  /*  not  integer  or  vaiable  */ 

return! 

) 

nextO!  /*  bypass  ease  variable  */ 

if  (  strcmp(token,"!")  ) 

(  errorOl)! 
return! 

> 

nextO!  /*  bypass  !  */ 

if  (  1  case.numo  ) 

<  if  (  st reap (token, "OTHERWISE")  ) 

(  error(32)! 

return! 

> 

nextO!  /*  bypass  otherwise  */ 

if  (  stremp(tok*n,"!")  ) 

<  errorOl)! 
return! 


/* 

*  CASE.num  executes  a  set  o£  statements  based  upon 

*  the  case  variable.  If  one  of  the  cases  matches 

*  the  value  of  the  case  variable,  that  set  of  statements 

*  Is  executed  and  true  Is  returned. 

*  otherwise,  false  is  returned. 

* 

*  Functions  used:  lookup,  next,  ease.num,  error(5S).  statements 

*  Globals  used:  token,  token. type,  syrrid,  symval 

*  Constants  used:  id. token,  lnt. token. 

* 

*  Author:  Dennis  J.  Ritaidato 

*  Last  update:  22  Sep  1993 

*/ 

tlnclude  <stdlo.h> 
ease.nunt  O 
< 

lnt  found: 
lnt  saveval: 

for  (foundafalse:  (strcmp( token, "OTHERWISE") 1*0)  &  (l  found);  ) 
{ 


•if  debugcase 

printf ("--Inside  for  loop.O); 
•erdlf 


if  (token.type  a»  ld.token) 

{  strcpy(symid, token) ; 

#lf  debugcase 

/* 

maybe  an  identifier 

*/ 

prlntf("An  identifier  token,  %s, 
•endif 

was  found 

, 0, token) ; 

nexto ; 

if  (  lstrc»p(token,":")  ) 

/* 

bypass  identifier 

♦  / 

<  nexto; 

/* 

bypass  : 

*/ 

If  (  l  lookucO  ) 
<  error(55); 


return(false) ; 

) 

If  (easeval  »*  symval)  /*  check  this  case  item  */ 

found  «  true;  /*  against  the  case  value  */ 

> 

> 

else  if  (token. type  a«  int. token)  /*  maybe  an  Integer  */ 

<  saveval  «  atol(token); 
sif  debugease 

printff"—  An  Integer  case  option  of  %d  was  found. 0. saveval) ; 

•endif 

nextC);  /*  bypass  integer  */ 

if  (  istrcmp(token,"i")  ) 

<  nexto;  /*  bypass  :  */ 

if  (easeval  »*  saveval)  /*  cheek  this  ease  item  */ 

found  ■  true;  /*  against  the  case  value  */ 

> 
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>  A 


> 

else  /*  roust  not  be  the  proper  */ 

<  while  (strcropC token , "  ? " )  )  /*  case  so  skip  rest  of  line*/ 

next( ) ; 

•If  debugcase 

orintf("--No  valid  case  nuro  was  found, 0); 

•endlf 


next?) t 

> 

/* 

bypass  ; 

*/ 

) 

/* 

end-for 

*/ 

•if 

debugcase 

printf ("— End  of  for  loop.OJi 
•endlf 


If  C  i  found  ) 
returnffalse) ; 
statements?)? 

while  (  strc»p(token,,,ENDCASE") 
next?); 
return(true) > 


/*  skip  remaining  statt 
/*  in  tne  case 


*/ 
•  / 

*/ 


/*  end-case. nuro 


/*  Loop  repeats  a  set  of  statements  a  specified  number 

*  of  times.  Any  number  of  repetitions  may  be  specified 

*  via  either  a  number  constant  or  variable  entry, 

*  Only  one  level  of  looping  is  implemented  in  this 

*  version.  To  implement  multiple  levels#  ehanqe  the 

*  loop. file  variable  name  to  an  array.  Then  step 

*  through  that  array. 

* 

*  Functions  used:  next#  error ( 23/55) ,  lookup 

*  Globals  used:  loop.ent,  symld#  symval#  loop. file 

*  token,  token. type,  string,  SDtr 

*  Constants  used:  int.token,  id. token,  linesiz,  null, 

*  LOOP. FILE 

* 

*  Author:  Dennis  J,  Ritaldato 

*  Last  update:  22  Sep  1983 
*/ 

•Include  <stdio,h> 

•include  "global . intern" 
loco.statement  () 

< 

lnt  save.ent  =  o; 

•if  debug 

printf ("LOOP.STATENENT  entered.!)); 

•endif 

If  (token.type  as  id.token) 

<  strcpyCsymid,  token); 
if  (  lookup()  ) 

save.ent  «  symval; 
else 

error (55) ; 

} 

else  if  (  token.type  as  int.token) 
save.ent  »  atol(token); 

else 

<  error(23); 
return; 

> 

nextO;  /*  bypass  loop  count  variable  */ 

/*  note:  */ 

/*  Each  line  must  terminate  with  a  newline  character.  */ 

/*  lin.len  should  always  point  to  this  newline  character.  */ 
/*  Exeept,  when  adding  a  string,  the  NEWLINE  is  added  at  the*/ 
/*  end  of  each  line  and  at  the  end  of  the  complete  string.  */ 

looo.f lie  ■  f open (LCD P.FILE , "w" ) ; 
while  (  strcmp(token, "ENDLCCP" )  ) 

(  if  (  token-tvpe  !«  str.token  ) 

<  fputsetoken, looo.f lie) ; 


/*  add  identifier/number  to  file*/ 


fputsCO, loop,  file); 

> 

else 

<  fouts(" 

fputs (string, loop. f lie) ; 
£outs(" 

> 

next () t 

} 

loop.cnt  a  save.cnt; 
fclosedoop-f  lie) ; 


/*  bypass  current  token 


f close (loop-file ) ;  /*  close  as  write  file 

/*  reopen  for  input 
loop.flle  *  f open(LCCP.F!LE , "r " ) ; 

•If  debualoop 

print# ( "—In  loop,  bypassing  token  %s0, token); 

•endlf 

nextO;  /•  bypass  the  word  "ENDLGOP" 

•If  debugloop 

prlntfC— Leaving  loop  with  token  %s0, token); 

•endi# 

return; 

>  /*  end  loop-statement 


*  »  »  -  -  -  '  . 
V.v-.- 


•Include  <stdio.h> 

•include  "global, interp" 
ereate  O 
< 

printf("  Create  entered. 0)» 
while  (tekenlOl  !*  #l') 
nextO  > 

>  /•  end  create 


•include  <stdlo.h> 

•include  "global. interp" 
dlsolay  () 

< 

print* ( "  DISPLAY  entered. 0); 
while  (tokenCOl  l* 
next0 1 

>  /*  end  dislpay 
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*  Error  performs  error  processing,  Depending  on  the  Input 

*  parameter  "type"  a  message  Is  printed  at  the  user's  console 

*  and  the  function  either  returns  or  terminates  the  nroqram. 

* 

*  Author:  Dennis  J.  Ritaldato  &  David  J,  Smanla 

*  Last  update:  22  Sep  1983 
*/ 

•include  <stdio,h> 

•Include  "global. interp" 
error  (type) 

int  type;  /*  ERROR  TYPES  ARE:  */ 

4 

if  (type  <»  10)  /*  l — i 0  System  errors  •/ 

4  printf  ("**♦*  SYSTEM  ERROR  ****  0); 
swlteh(type) 

4  case  l: 
exito; 
ease  2: 

printf  ("Symbol  table  exceeded. 0); 
exitO; 
case  3: 

printf  ("Premature  end  of  input  encountered. 0) ; 
exito; 
case  4: 

printf  ("Unrecognized  character,  %c,  in  line:0,*iptr) ; 
printf  ("%s0, line  ); 
return; 
case  5: 

printf  ("String  length  exceeds  %d  in  iine:0 , stringsiz) ; 
printf  ("%s0,iine); 
exito ; 
case  6: 

printf ("Unable  to  open  file  •  check  <FN>  is  capltallzedO) ; 
exito; 
return; 

>  /*  endcase  * 

>  /*  endif  1-10  * 

else  if  (type  <■  50)  /*  if  11-50  Reserved  word  * 

<  printf  ("****  SYNTAX  ERROR  ***»  0);  /*  syntax  errors  */ 
switch(type) 

4  ease  li: 

printf ("PROGRAM"); 
break; 
case  12: 

printf ("AN  IDENTIFIER"); 
break; 
ease  14: 

printf ("END."); 
break; 
case  16: 

printf ("THEN"); 


break; 
ease  17: 

brintf ("ENCIF") ; 
break; 
ease  19: 

orintf (•*"); 
break; 
ease  20: 

printf ("Device  "CRT"  or  a  f ilename" ) ; 
break; 
ease  21: 

printf("AN  ARITHMATIC  OPERATOR "  ) ; 
break; 
ease  22: 

Drintf("AN  ARITHMETIC  EXPRESSION"); 
break; 
ease  23: 

prlntf("An  integer  or  variable  loop  count"); 
break; 
ease  24: 

printf("An  integer,  identifier,  string  or  expression"); 
break; 
ease  25: 

printf ("Device  #CRT#  or  'LST*  or  a  filename"); 
break; 
ease  26: 

printf ("Filename  —  (<FN>  (,<FT>J)  —  "); 
break: 
ease  27: 

printf("--  )  —  "); 
break; 
ease  30: 

orintf ("Fiietype  —  (<FN>  [,<FT>J)  --"); 
break; 
ease  31: 

printf("—  :  --"); 
break; 
ease  32: 

printf ("OTHERWISE") ; 
break; 
ease  33: 

printf ("ENDCA5E"); 
break; 
default: 

printf  ("  sssss  system  error  i  l  -  %d  sssss  ",type); 

printf  ("  PLEASE  NOTIFY  EITHER  DENNIS  J.  RITALDATO  (215)  "); 
Orintf  ("441-2107  CR  DAVID  J.  SMANIA  (408)  646-8182.  0); 
return; 

)  /*  endcase  */ 

printf  ("  was  expected,  but  %s  was  found  at  %s, 0, token, lptr) ; 
while  (tokenCO)  1»  *;')  /*  skip  remainder  of  line  */ 

nextO ; 


ill 


return) 


> 

/* 

endlf  11-30 

*/ 

else  If  (type  <*  70) 

<  switeh(type) 

/* 

if  51-70  General  syntax 

*/ 

<  ease  51: 

/* 

errors 

*/ 

printf  ("No  legal  Command  Language  statement  was  found”); 
break; 
ease  S3: 

printf  (";  expected"); 
break; 
ease  54: 

prlnt£("An  IF  statement  must  nave  a  logical  expression"); 
break; 
ease  55: 

printf ("Undefined  Identifier,  Is  ", token); 
break; 
ease  56: 

printf ("Cannot  read  from  the  list  devlee"); 
break; 
ease  57: 

orlnt£("Data  type  mismatch.  A  string  type  was  expected”); 
break; 
ease  56: 

return; 
ease  59: 

return; 
ease  60: 

return; 

default: 

printf  ("SSSSS  SYSTEM  ERROR  «  1  -  %d  SSSSS  ",type); 

Printf  ("  PLEASE  NOTIFY  EITHER  DENNIS  J.  RITALDATO  (215)  ") 

printf  ("  441-2107  OR  DAVID  J.  5MANIA.  0); 

return; 

>  /♦  endcase  */ 

printf  ("  at  Is  In  line : 112s0 ,letr , line) ; 

while  (  strcmp(token,";")  )  nextO;/*  skip  rest  of  line  */ 

>  /*  endlf  51-70  */ 

/*  end  error  */ 
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